Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Wed, Aug 17, 2011 at 12:27:14PM +0200, Gioele Barabucci <gioele@svario.it> wrote:
I was wondering why the git tags are named `3.3.4.2` for 3.3.4-rc2 
instead of the more natural `3.3.4-rc2` or the more common `v3.3.4-rc2`. 
I am used to see 3.3.4.2 as the second bugfix release for 3.3.4, or, in 
more mathematical terms, 3.3.4.2 > 3.3.4 = 3.3.4.0. I hope 3.5-rc1 will 
not be tagged as 3.5.1.

Is this behaviour a leftover of the SVN workflow? Could it be changed?

The problem is that when 3.4.x.y is tagged in git, nobody knows if it
will be the last RC or not. The final 3.4.x release is always the same
as the last RC, and there is only one 3.4.x.y tag for them.

An alternative would be what KDE does (or something similar, Lubos may
know better): when the RC is supposed to be the last one, then tag it as
3.4.x, then release the tarballs in a private packager list, repack
tarballs without incrementing version number when critical issues found,
then release to the public.

IMHO not having private source tarballs and not having private repacks
worths having two (3.4.x-rcy and 3.4.x.y) versionings.

Attachment: pgpwkWjT7Nau_.pgp
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.