On Wed, Aug 17, 2011 at 12:27:14PM +0200, Gioele Barabucci <gio...@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.
pgpF9fgxDULPn.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
