wayland-protocols versioning between releases
jadahl at gmail.com
Mon Feb 22 09:19:01 UTC 2016
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?
> 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.
> 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
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.
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.
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.
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.
> FWIW, it seems pkg-config regards 1.2.0 to be greater, not equal, to
> 1.2 for instance.
More information about the wayland-devel