[Libreoffice] Git tags: why not "3.3.4-rc2" instead of ""

Tomáš Chvátal tchvatal at novell.com
Fri Aug 19 01:09:49 PDT 2011

Dne 18.8.2011 19:37, Gioele Barabucci napsal(a):
> On 18/08/2011 16:15, Miklos Vajna wrote:
>> On Wed, Aug 17, 2011 at 12:27:14PM +0200, Gioele 
>> Barabucci<gioele at svario.it>  wrote:
>>> I was wondering why the git tags are named `` 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 as the second bugfix release for 3.3.4, or, in
>>> more mathematical terms,>  3.3.4 = 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.
> Sorry, but I do not understand. What I'd do to release `3.4.1-rc2` is
> 1. tag current commit with `v3.4.1-rc2`,
> 2. ask for review,
> 3. if no problem is found, tag same commit with `v3.4.1`.
> In case changes are needed:
> 3b. make change and tag the current commit with `v3.4.1-rc2`,
> 4. ask for another review,
> 4. tag same commit with `v3.4.1`.
> Also in this case you have only one `3.4.X-rcY` tag for each `3.4.X`.
> There must be something that I miss...
Yes you can simply re-tag it, repack the tarballs but what about those 
poor guys
that are using the tarballs and installed such version.

They would have to recompile the libreoffice just to have "newer" 
version that does
not change at all.

And users usually don't bother if we call the day with or with 
3.4.3 alone.

Opposite point for this would be to call it 3.4.3 all the time and just 
change the version
internally, which is not so comfy like current approach.



More information about the LibreOffice mailing list