wayland-protocols versioning between releases

Mon Feb 22 11:10:37 UTC 2016

On Mon, Feb 22, 2016 at 12:44:46PM +0200, Pekka Paalanen wrote:
> On Mon, 22 Feb 2016 17:19:01 +0800
> Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > On Mon, Feb 22, 2016 at 11:04:16AM +0200, Pekka Paalanen wrote:
> > > Hi Jonas,
> > > 
> > > I have a small version dependency issue when preparing a patch set to
> > > stabilize the Presentation extension. I want to write a final patch set
> > > to be landed into both wayland-protocols and weston, send it to the
> > > list, and let people be able to test it as usual.
> > > 
> > > A weston patch needs to bump the wayland-protocols version requirement.
> > > If I bump it to 1.2 assuming the wayland-protocols patches will be
> > > included in 1.2 release, people will have to hack either the
> > > wayland-protocols.pc file or the dependency check in weston to be able
> > > to test my patches.  
> > 
> > Why would adding a "depending on master" check help if the patches are
> > not on the master branch of that dependency anyway?
> 
> Hi,
> 
> testers will apply patches to both trees when testing. If weston
> patches can already at that point say "depends on wayland-protocols
> *after* release 1.1", those patches can be landed in weston without any
> last minute changes, and testers do not have to hack the version checks.
> 
> > > If I don't bump the requirement in weston in the patch series I send
> > > out for review, there is a danger of forgetting to do it when landing
> > > the series.  
> > 
> > You still have to remember it. Just now from changing x.y.9 to x.y+1.0.
> 
> No, a second bump is not necessary. Weston can very well be left
> depending on >= x.y.9, because the first wayland-protocols release that
> will satisfy it will be x.(y+1).0 or even x.(y+1), plus all following
> releases satisfy it as well.
> 
> Nothing says that x.y.9 should be a release. 1.x.90 under the current
> policy in wayland or weston is never a release version either.
> 
> Demanding that the release manager reviews all version dependencies at
> the time of Weston's release and bumps them accordingly (or even checks
> they are correct) would be a burden I do not want to inflict.

The patch merger will still need to double check this dependency when
merging the patches in order to make sure the upstream master branch or
the latest release contains the relevant patches. Having to bump the
version dependency is added manual work, of course, which is not nice.

> 
> > > 
> > > I would not want to have a release of wayland-protocols before the
> > > weston patches have been reviewed either.
> > > 
> > > I suggest we make a wayland-protocols version number policy that allows
> > > other projects to depend on master between releases. We already do
> > > this with Wayland and Weston by having a version bump to 1.x.90 right
> > > after the release of 1.x.0. Another way would be to use even vs. odd
> > > versions like Pixman does.
> > > 
> > > How should we redefine the versioning, add a third number or go for
> > > even/odd?  
> > 
> > I don't really see the point of it. The testers of your patch branches
> > are probably well aware that they need to apply both branches, and it
> > should be obvious that wayland-protocols would need to be applied and
> > installed before weston, given the order of dependency.
> 
> Yes, but *in addition* to applying patches to both trees, they right
> now will have to fake the wayland-procols version or hack Weston's
> wayland-protocols version check.
> 
> I want to get rid of putting testers through such pain, while allowing
> them to review the final, landable patches.
> 
> My branches or patches cannot bump wayland-protocols version to 1.2,
> because that happens at wayland-protocols release time. My branches
> also must carry the Weston dependency bump, because otherwise it may be
> forgotten.

My point was that you don't bump any versions until actually merging, so
testers need to do no tweaking at all.

> 
> > If you get an error saying "you need wayland-protocols 1.1.9", if one
> > actually blindly follows that dependency and installs the master branch,
> > one'll now instead just get the error as if you didn't touch the
> > dependency version to begin with.
> 
> The bump to 1.1.9 in wayland-protocols has to be done
> immediately after the 1.1 release.

My point is that you add a dependency on version X, which more or less
means "master branch at least after version Y". That version does not
include the patches that you happen to depend on.

> 
> > I would prefer that patch series just left the dependency unchanged
> > until its time for actual merging, at which point the dependency can be
> > properly increased to the version including the patches on the package
> > that is depended on.
> 
> We have a very simple way to avoid that possibility for a human error.
> Why not take it?
> 
> I expect the first version of the patch series to be final, too.
> 
> > Only if there is actual need for having the wayland-protocols unreleased
> > for a time while the patches are brewing on weston would I see a need to
> > add micro versions. But that doesn't seem like a thing that should be
> > encouraged since it'd mean such state would block any other protocol
> > from being updated until the lingering protocol updates are deemed Ok.
> 
> No, that is not what I mean.
> 
> I simply want, that I can post final patches for testing and review,
> and people can apply the whole set for the two trees, and just test
> them. And then anyone at upstream can land both series, without having
> to remember to bump any versions.
> 
> It is much easier to verify that the wayland-protocols patches have
> landed there before landing the weston patches that depend on them, and
> I agree that is a good policy to keep. If I sent weston patches that
> didn't bump any version requirements, you would still have to manually
> check that a) the wayland-protocols patches have landed and been
> released first, and b) revise the weston to patch bump dependencies.
> 
> We do this between wayland and weston all the time, why not with
> wayland-protocols?

The reason for doing it in wayland/weston is different. There it is
about actually depending on the other's master branch, not on branches.

> 
> Maybe the problem becomes obvious if I post my Presentation patches as
> is?

If I haven't misunderstood you want to add dependency on
"wayland-protocols release after N" by adding a N.9 after releasing N,
in order to send two patch series that depends on each other that the
merger needing to deal with checking version dependencies.

But for example if you post them, bumping the version to 1.1.9. Then in
a couple of days, before it has been finished review etc, we merge some
other protocol to wayland-protocols, such as the tablet protocol,
primary selection, and then make a new release. If this happens, which
is not highly unlikely, the patch merger still needs to do version
checking and version bumping etc.

> 
> I want the weston patches to be reviewed *before* landing the
> wayland-protocols patches. Then wayland-protocols patches land, and
> then weston patches land. I would actually think that this would be
> quite common, just not with weston but any other compositor project
> that has patches for implementing a new protocol not yet landed in
> wayland-protocols. You often want to check and test the tentative
> implementation before accepting a new protocol spec.
> 
> Or do you think a much better idea instead would be to have weston
> patches not bump dependencies but add a comment near the dependency
> check that one must remember to adjust this before making a weston
> release?

I don't have better ideas, I just don't think adding the micro version
will save us that much trouble.

The side effects, being at least slightly annoying, of doing such thing
is either having the wayland-protocols.pc version format be different
from the version format from releases, or prefix every single
wayland-protocols version with .0. How do you imagine that would work?

Jonas

> 
> 
> Thanks,
> pq