wayland-protocols versioning between releases

[Bryce Harrington]

On Mon, Feb 22, 2016 at 02:04:04PM +0200, Pekka Paalanen wrote:
> On Mon, 22 Feb 2016 19:10:37 +0800
> Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > 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.
> 
> Hi,
> 
> yeah, checking at the time of merging a patch is necessary, and bumping
> the dependency at the same time is also doable if not nice. Having to
> review the whole history since the last release to find out needed
> version bumps is what I strongly oppose.

Using .90 doesn't solve every possible glitch that could happen in the
release process, and I agree that in practice these situations will be
mostly obvious and well-known, and whomever lands the patch should be
on top of noticing dependencies on unreleased changes from
wayland-protocols.  Indeed I suspect in many cases one would find stuff
fails to compile when the protocol changes are missing, so it'll be
pretty obvious.

But that said, I agree with pq.  Using x.y.90 to indicate "current git"
seems to be a widespread practice in X (and in Wayland/Weston), and
gives us an easy shorthand way to quickly communicate dependencies that
most people will immediately understand.

> > > > > 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.
> 
> Yes, this is what we disagree upon.
> 
> > > > 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.
> 
> Yet we use this scheme with everything else.

Agreed, this is pretty standard, I'm not sure I understand why it
wouldn't be appropriate for this case too.
 
> > > > 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.
> 
> Sorry, what do you mean by "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.
> 
> More than two in an atomic series, but yes.
> 
> > 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.
> 
> That's true. This one is actually a good reason against my proposal,
> showing that I cannot save the effort from the person merging the
> weston patches.

On the contrary, if I were reviewing a patch that among other things
bumped wayland-protocols to a 1.1.90, that would be a big red flag that
I'd better doublecheck that the protocol did indeed go into 1.2.0.

Sure, in this particular case the technical mechanics of the version are
subverted, but again I see the main value to this being a communication
shorthand, and that aspect isn't lost in this situation.

Now, you could envision a situation where patchset #1 sets
wayland-protocols to .90 and is landed, and then patchset #2 comes along
which also has a dependency but doesn't set .90 since the previous
patchset already did, then I could see this second patchset potentially
slipping through.  wayland-protocols releases have been frequent enough
so far though that I'm doubtful this corner case would be likely to
occur very often.  I suppose if it did the patch could always just bump
to .91 or whatever.

> > > 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.
> 
> I actually think going for even/odd is better suited for
> wayland-protocols, because there would never be a release with a micro
> version not zero.

>From what I've seen in maintaining cairo, which uses this even/odd
scheme, it is a perennial source of confusion.  wayland-protocols is
much less end user focused so maybe that's not as big of a deal here,
but I still would be unfavorable to use it.

Bryce