[PATCH weston v2 1/4] releasing: how to handle libweston

[Quentin Glidic]

On 15/08/2016 14:16, 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>
> Reviewed-by: Jonas Ådahl <jadahl at gmail.com>

Clear and nice:
Reviewed-by: Quentin Glidic <sardemff7+git at sardemff7.net>

Cheers,


> ---
>  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]"
>


-- 

Quentin “Sardem FF7” Glidic