wayland-protocols versioning between releases

[Jonas Ådahl]

On Mon, Feb 22, 2016 at 02:08:10PM -0800, Bryce Harrington wrote:
> 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.

The difference is that X, weston, wayland, cairo and what not will have
relevant patches in git that others depend on, while when
wayland-protocols sees relevant commits (introduction of new protocol),
you'd normally see a release shortly after.

> 
> > > > > > 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.

The scheme commonly used is AFAIU to depend on commits on the master,
not on unmerged patch series. And wayland-protocols should not be
compared to wayland, cairo etc, it should rather be compared to the
repositories under xorg/proto/ which doesn't seem to follow the .90 or
odd/even version number semantics.

>  
> > > > > 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.

An even bigger flag would be to add a reminder comment, as Pekka
mentioned, and the protocol could just as well have been merged in 1.5.
The "1.1.90" doesn't really provide any useful information.

> 
> 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.

More things can go wrong. patchset #1 depending on protocol A sets the
dependency to N.90. Then patchset #2 that depends on protocol B doesn't
change it. Then protocol B gets merged and wayland-protocols sees a N+1
release. Now patchset #1 has the wrong version as well.

> 
> > > > 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.

Yea, I don't like the odd vs even versioning thing. Nor do I see a good
enough reason to introduce a meaning-less number just to depend on
"version after N" where that dependency is not guaranteed to be more
valuable than "version N".


Jonas

> 
> Bryce