Version numbering

Version numbering

[Lars Ingebrigtsen]

I had a brain fart last night while doing the first git-based release.

I added the "is released" stuff and pushed it out, and then bumped and
tagged the stuff as "n0-12".

But, of course, if you pull down n0-11, you get a two year old version
of Gnus.  To get No Gnus v0.11, you need to pull down the version just
before it got tagged as n0-12.  That's obviously not any good.

So I think what I should have done is bump the version number, tag as
n0-12, say "No Gnus 0.12 is released", and then bump the version to
0.13, and tag as n0-13.  So that the even ones are the things people can
download if they want a specific version.

Alternatively, since that's pretty complicated, I could just bump the
version, tag, release, and then not bump the version.  So instead of the
version number being "trailing", it would be, er, "leading".

Or I could bump the version, tag, release, and bump the version again
without tagging.  That way there will be a tag for every two releases,
so the next tag will be n0-13, and then n0-15, and so on.

That would mean that all tags will be "releases", but there wouldn't be
as many of them as there are versions.

Hm.  I like this last option best, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbering

[Richard Riley]

On Tue, Feb 22, 2011 at 12:07 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> I had a brain fart last night while doing the first git-based release.
>
> I added the "is released" stuff and pushed it out, and then bumped and
> tagged the stuff as "n0-12".
>
> But, of course, if you pull down n0-11, you get a two year old version
> of Gnus.  To get No Gnus v0.11, you need to pull down the version just
> before it got tagged as n0-12.  That's obviously not any good.
>
> So I think what I should have done is bump the version number, tag as
> n0-12, say "No Gnus 0.12 is released", and then bump the version to
> 0.13, and tag as n0-13.  So that the even ones are the things people can
> download if they want a specific version.
>
> Alternatively, since that's pretty complicated, I could just bump the
> version, tag, release, and then not bump the version.  So instead of the
> version number being "trailing", it would be, er, "leading".
>
> Or I could bump the version, tag, release, and bump the version again
> without tagging.  That way there will be a tag for every two releases,
> so the next tag will be n0-13, and then n0-15, and so on.
>
> That would mean that all tags will be "releases", but there wouldn't be
> as many of them as there are versions.
>
> Hm.  I like this last option best, I think.

Why not only tag releases and then use a development branch for all
ongoing work until the next merge and tag release party?

Re: Version numbering

[Lars Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> Why not only tag releases and then use a development branch for all
> ongoing work until the next merge and tag release party?

Development happens on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbering

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Richard Riley <rileyrg@googlemail.com> writes:
>> Why not only tag releases and then use a development branch for all
>> ongoing work until the next merge and tag release party?

> Development happens on the trunk.

Then you could make a branch called "releases".

If there hasn't been anything happening on the release branch since the
last release, doing a merge from master is a simple (and low-cost (since
it will be a ff-merge)) operation:
 git checkout releases
 git merge master
thazzit!

You could put a tag on releases after the merge master.

The releases branch will become an exact copy of master, but
time-deleayed.

Re: Version numbering

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Then you could make a branch called "releases".
>
> If there hasn't been anything happening on the release branch since the
> last release, doing a merge from master is a simple (and low-cost (since
> it will be a ff-merge)) operation:
>  git checkout releases
>  git merge master
> thazzit!

Hm...  that seems like a kinda handy solution for people who want to
stay updated via git, but only wants the releases.  Any objections to
doing it this way, all y'all?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbering

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Wed, Feb 23 2011, Lars Ingebrigtsen wrote:

> Hm...  that seems like a kinda handy solution for people who want to
> stay updated via git, but only wants the releases.  Any objections to
> doing it this way, all y'all?

Yeah, what Steiner describes is a good and easy solution if you want to
provide a branch where its HEAD is always pointing at a release. So go
ahead.

(Just never commit anything in that branch! :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Version numbering

[Lars Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Yeah, what Steiner describes is a good and easy solution if you want to
> provide a branch where its HEAD is always pointing at a release. So go
> ahead.

On the other hand, the difference between saying "git checkout n0-15"
and saying "git pull" in the right branch is pretty negligible.  And
since using two branches is more work for me, I'm probably not going to
go that route.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbering

[Steinar Bang]

>>>>> Julien Danjou <julien@danjou.info>:

> Yeah, what Steiner describes 

Who is this "Steiner" you all keep talking about?

Re: Version numbering

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

On Wed, Feb 23 2011, Steinar Bang wrote:

> Who is this "Steiner" you all keep talking about?

It's some guy sending emails to me exclusively.
So you can't know him, sorry.

;-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Version numbering

[Andreas Schwab]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I think what I should have done is bump the version number, tag as
> n0-12, say "No Gnus 0.12 is released", and then bump the version to
> 0.13, and tag as n0-13.

What's the point of the n0-13 tag?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Version numbering

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> So I think what I should have done is bump the version number, tag as
>> n0-12, say "No Gnus 0.12 is released", and then bump the version to
>> 0.13, and tag as n0-13.
>
> What's the point of the n0-13 tag?

In that scenario, no point, which is why I suggested a different method
at the end of the article.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbering

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Tue, Feb 22 2011, Lars Ingebrigtsen wrote:

Or you could do like Org mode, and use git describe to get a dynamic
gnus-version:

% git describe
n0-13-16-g3787aa1

`org-version' calls the git executable, which is probably not the best
way to do it. The best way is IMHO to do something in the build process
that either set the version to 0.N (like it is currently done) or find
the version by running `git describe'.

This is what we do in awesome for a long time, it works very well. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Version numbering

[Lars Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Or you could do like Org mode, and use git describe to get a dynamic
> gnus-version:
>
> % git describe
> n0-13-16-g3787aa1

I have a feeling that this wouldn't really be all that useful for Gnus.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbering

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

On Wed, Feb 23 2011, Lars Ingebrigtsen wrote:

> I have a feeling that this wouldn't really be all that useful for
> Gnus.

But at least it would be correct.
I can write the code if that's needed.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Version numbering

[Erik Colson]

Julien Danjou <julien@danjou.info> writes:

> On Wed, Feb 23 2011, Lars Ingebrigtsen wrote:
>
>> I have a feeling that this wouldn't really be all that useful for
>> Gnus.
>
> But at least it would be correct.

I slightly have the same idea about this...

A 'release branch' which _only_ holds release commits will soon become a
problem if one of the devs forgets this and pushes a non-release commit
to the branch :/

Best

-- 
erik colson
ecocode.net

Re: Version numbering

[Steinar Bang]

>>>>> Erik Colson <eco@ecocode.net>:

> A 'release branch' which _only_ holds release commits will soon become
> a problem if one of the devs forgets this and pushes a non-release
> commit to the branch :/

It is possible to limit pushes to a branch to some users (or maybe only
one?). 

If people use rebase before pushing instead of merging then all new
commits should come chronologically after the previous head, and then it
is possible to do a reset on the release branch.

But of course, here we are talking about people messing up, and when
they do, they usually do it in spite of all safeguards you put up.

Worst case, you can delete the release branch, and create a new release
branch from some point in time on master.

On git, recovery is possible... in most cases... just keep calm, and
don't panic.

Re: Version numbering

[Lars Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> I can write the code if that's needed.

I think having the version numbering we have now is sufficient and nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen