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<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.
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 3.4.3.3 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.
Cheers
Tom
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
