Gioele Barabucci | 17 Aug 12:27 2011
Picon

Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

Hello,

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?

Best,

--
Gioele Barabucci <gioele@...>

Miklos Vajna | 18 Aug 16:15 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

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 `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.
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 `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.
> 
(Continue reading)

Gioele Barabucci | 18 Aug 19:37 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

On 18/08/2011 16:15, Miklos Vajna wrote:
> On Wed, Aug 17, 2011 at 12:27:14PM +0200, Gioele
Barabucci<gioele@...>  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...
(Continue reading)

Michael Meeks | 18 Aug 21:40 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"


On Thu, 2011-08-18 at 19:37 +0200, Gioele Barabucci wrote:
> On 18/08/2011 16:15, Miklos Vajna wrote:
> > On Wed, Aug 17, 2011 at 12:27:14PM +0200, Gioele
Barabucci<gioele@...>  wrote:
> >> Is this behaviour a leftover of the SVN workflow? Could it be changed?

	Why is it worth changing ? :-) certainly anything can be changed; but
why bother ? There is no problem I can see with releasing 3.5.0.3, the
numbers increase in a sensible fashion, and can be trivially compared by
machine and eye.

	It looks like yet-another bikeshed to me :-) I'd be more concerned that
git tag -l on the 'core' repo has dozens of tags for the same version:
artwork_libreoffice-3.4.0.2 base_libreoffice-3.4.0.2 etc. personally ;-)
suggestions for cleaning that up much appreciated.

	ATB,

		Michael.

--

-- 
 michael.meeks@...  <><, Pseudo Engineer, itinerant idiot

Norbert Thiebaud | 18 Aug 22:31 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

On Thu, Aug 18, 2011 at 2:40 PM, Michael Meeks
<michael.meeks@...> wrote:
>
> On Thu, 2011-08-18 at 19:37 +0200, Gioele Barabucci wrote:
>> 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:
>> >> Is this behaviour a leftover of the SVN workflow? Could it be changed?
>
>        Why is it worth changing ? :-) certainly anything can be changed; but
> why bother ? There is no problem I can see with releasing 3.5.0.3, the
> numbers increase in a sensible fashion, and can be trivially compared by
> machine and eye.
>
>        It looks like yet-another bikeshed to me :-) I'd be more concerned that
> git tag -l on the 'core' repo has dozens of tags for the same version:
> artwork_libreoffice-3.4.0.2 base_libreoffice-3.4.0.2 etc. personally ;-)
> suggestions for cleaning that up much appreciated.

micahel, that was done on purpose to be able to 'match' before and
after conversion.

each repos before conversion had a given tag... I renamed them
prefixing the old repo name in order to preserve what that tag was in
that repos.
it is not very obvious how to use it, but modulo some scripting and or
some gitk/git rev-list trickery it is possible to use tat information
to some-how still navigate the old history.

btw: gitk --date-order is useful for these case (you'll see all these
similar tag clumped together)
(Continue reading)

Bjoern Michaelsen | 19 Aug 00:40 2011

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

Hi Michael,

On Thu, 18 Aug 2011 20:40:13 +0100
Michael Meeks <michael.meeks@...>
wrote:

> 	It looks like yet-another bikeshed to me :-) 

Indeed.

> I'd be more concerned that git tag -l on the 'core' repo has dozens
> of tags for the same version: artwork_libreoffice-3.4.0.2
> base_libreoffice-3.4.0.2 etc. personally ;-) suggestions for cleaning
> that up much appreciated.

While you are clearly hijacking this thread ;) the solution should be
rather simply: merge all the repo-tags for each tag and tag that joined
commit. After creating those tags, all the separate tags could be
removed for readability proposes. Before doing so, maybe we should just
dump the output of:

 for tag in `git tag`;do echo $tag `git rev-list --no-walk $tag`; done

in dev-tools/onegit so that we could regenerate those in an emergency.

Best,

Bjoern

--

-- 
(Continue reading)

Norbert Thiebaud | 19 Aug 06:44 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

On Thu, Aug 18, 2011 at 5:40 PM, Bjoern Michaelsen
<bjoern.michaelsen@...> wrote:
> Hi Michael,
>
> On Thu, 18 Aug 2011 20:40:13 +0100
> Michael Meeks <michael.meeks@...>
> wrote:
>
>>       It looks like yet-another bikeshed to me :-)
>
> Indeed.
>
>> I'd be more concerned that git tag -l on the 'core' repo has dozens
>> of tags for the same version: artwork_libreoffice-3.4.0.2
>> base_libreoffice-3.4.0.2 etc. personally ;-) suggestions for cleaning
>> that up much appreciated.
>
> While you are clearly hijacking this thread ;) the solution should be
> rather simply: merge all the repo-tags for each tag and tag that joined
> commit. After creating those tags, all the separate tags could be
> removed for readability proposes.

by doing that you would be creating new commits completely out of
order of the history... essentially creating a cactus on top of n old
repos history with a bunch of leaf-tags. (that is dead-end 18 commit
branch just to merge them all -- since at least .gitignore conflict,
that make octopus merge problematic -- with the tag at the end of
it... without any connection to the tag before or after it)

All in all, a lot of work that will just add lots of ugliness to the
(Continue reading)

Bjoern Michaelsen | 19 Aug 09:49 2011

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

On Thu, 18 Aug 2011 23:44:16 -0500
Norbert Thiebaud <nthiebaud@...>
wrote:

> by doing that you would be creating new commits completely out of
> order of the history... essentially creating a cactus on top of n old
> repos history with a bunch of leaf-tags. (that is dead-end 18 commit
> branch just to merge them all -- since at least .gitignore conflict,
> that make octopus merge problematic -- with the tag at the end of
> it... without any connection to the tag before or after it)

Merging the "last tag"+"all repo tags" should leave you with
non-leaf-tags, e.g. you do:
git checkout -b libreoffice_3.3.0 \
    bootstrap_libreoffice-3.3.0.2
git merge sdk_libreoffice-3.3.0.2 writer_libreoffice-3.3.0.2 ....
git checkout master -- .gitignore
git add -u .gitignore
git commit -m "merged tag libreoffice-3.3.0.2"
git tag libreoffice-3.3.0.2
git merge bootstrap_libreoffice-3.3.0.3 sdk_libreoffice-3.3.0.3 ....
git checkout master -- .gitignore
git add -u .gitignore
git commit -m "merged tag libreoffice-3.3.0.3"
[repeat for each tag on 3.3.0]
[repeat all for each branch]

The tagbranch (do we actually have tags on master after the last
release branchoff?) for master should be merged to master with:
git checkout master
(Continue reading)

Tomáš Chvátal | 19 Aug 10:09 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

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@...>  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`.
(Continue reading)

Tomáš Chvátal | 19 Aug 10:19 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

Dne 18.8.2011 16:15, Miklos Vajna napsal(a):
>
> 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.
>
Please don't.
We always really loved how the tarballs change under our hands
when working on KDE releases.

The time period in KDE is required because the tarballs often
won't build due to different layout in svn/git compared to them.
So the repacking happen more due to build fixes than to bug fixes
that are done with libreoffice.

I bit know what I am saying as I was KDE Team lead on Gentoo for
one year.

Cheers

Tom
Petr Mladek | 22 Aug 11:57 2011
Picon

Re: Git tags: why not "3.3.4-rc2" instead of "3.3.4.2"

Gioele Barabucci píše v St 17. 08. 2011 v 12:27 +0200:
> Hello,
> 
> 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 tag version is used for the source tarballs. They are used by distro
packagers. They do not like letters in the version. The letters work
well for alpha/beta/rc because the alphabetical order is correct. But
how to name the final build? 3.4.0 is considered as an older version
than 3.4.0rc1 by rpm. We do not want to keep rc in the final build
because it confuses users.

>From my point of view. Only developers and packagers take care of the
tag name. The current naming scheme is pretty clear for developers and
useful for packagers, so I vote to keep it ;-)

Best Regards,
Petr

_______________________________________________
LibreOffice mailing list
LibreOffice <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
(Continue reading)


Gmane