wayland-protocols versioning between releases

Mon Feb 22 10:44:46 UTC 2016

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.

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

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

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

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

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?

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160222/4e16e77a/attachment-0001.sig>