[PATCH weston 1/2] releasing: how to handle libweston
jadahl at gmail.com
Mon Aug 15 09:06:02 UTC 2016
On Wed, Aug 10, 2016 at 03:01:12PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> libweston has separate version numbering from weston because of
> development needs.
> During development, weston version is major.minor.90 which will never be
> a release version number. While developing, we may break the libweston
> backward-compatibility, in which case libweston_major_version will be
> bumped. This means that libweston_major_version > weston_major_version
> but only during the development period and for the pre-releases. When
> the official x.y.0 release is made, weston and libweston versions will
> get synchronized as explained in releasing.txt.
> The reason we do this is that e.g. during the weston 3.0.90 development
> period we must be able to install libweston-4.so because the development
> has broken the compatibility and so we cannot install it as libweston-3.so
> anymore. However, we cannot bump weston to 4.0.90, because then the
> official release would go backwards in numbers to 4.0.0.
> This also means that weston pre-releases major.minor.9x may install
> libweston-(major+1).so. There is also libweston-(major+1).pc file but it
> will give the weston version as the version number. IOW, pkg-config
> check for 'libweston-M < M.0.0' matches only the pre-releases of the
> libweston major version M. Hence, 'libweston-M >= M.0.0' cannot be
> satisfied by pre-releases.
> The weston and libweston version numbers MUST be identical in all
> releases except the pre-releases major.minor.9x.
> When the 1.11.91 pre-release is made, the rules imply that libweston
> version will be bumped from 0.0.0 to 1.11.91. The bumping will continue
> up to the 1.12.0 release. After the bump to 1.12.90, the libweston
> version may be bumped to 2.0.0. Then the rules imply that:
> - 1.12.9x pre-releases install libweston 2.0.0
> - the next .0 release is 2.0.0 containing libweston 2.0.0
> If the 1.12 stable branch will see additional releases, those will be
> numbered 1.12.1, 1.12.2, etc. with the libweston version being the same
> as the release version number.
> If we have release 2.0.91 without libweston major bump, then libweston
> version will match the release version, leading up to 2.1.0.
> Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
I tried to go through the various scenarious and apply the rules added
below and it seems to hold up. Some things could be made more obvious,
but maybe not in the text below. For example, do we ever document how
"bumping" works, and that it may only be done at most once per major
Reviewed-by: Jonas Ådahl <jadahl at gmail.com>
> releasing.txt | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
> diff --git a/releasing.txt b/releasing.txt
> index 0aae23a..b30991f 100644
> --- a/releasing.txt
> +++ b/releasing.txt
> @@ -10,7 +10,20 @@ To make a release of Weston and/or Wayland, follow these steps.
> release with any needed protocol updates.
> 2. Update the first three lines of configure.ac to the intended
> - version, commit. Then commit your changes:
> + version.
> + For Weston's x.y.0 releases, if libweston_major_version is greater than
> + weston_major_version, bump the Weston version numbers (major, minor,
> + micro) to match the libweston version numbers (major, minor, patch).
> + Additionally for all Weston releases, if libweston version
> + major.minor.patch is less than Weston version major.minor.micro, bump
> + libweston version numbers to match the Weston version numbers.
> + Weston releases are made with the Weston version number, not with the
> + libweston version number.
> + Then commit your changes:
> $ export RELEASE_NUMBER="x.y.z"
> $ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel