[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep release numbers
From: |
Richard Frith-Macdonald |
Subject: |
Re: gnustep release numbers |
Date: |
Wed, 4 Oct 2006 12:30:08 +0100 |
On 4 Oct 2006, at 11:51, Helge Hess wrote:
Hi,
could we please change the numbering scheme for GNUstep releases?
In my understanding:
Currently when Adam does a release he bumps the soname version (eg
from 1.12.0 to 1.13.0) in trunk and then tags the release. That
means after the release, trunk will continue carrying that tag.
I propose a simple modification: Also bump the version after a
release so that trunk libs can be identified properly.
I proposed somethog similar back in August ...
On Aug 9, 2006, at 7:10 AM, Richard Frith-Macdonald wrote:
I understand the problem, but I don't think the best solution is
to add new macros and scripting. Rather, I think it's to adopt a
slightly more rigorous approach to making releases. What I
propose is this ...
When we make a release, we make a branch in svn into which any
bugfixes will be applied.
Immediately after making the release, we increase the minor
version number in trunk.
After a release, if we need to make a bugfix release, we do it by
incrementing the subminor version number in the branch and
releasing a snapshot of the branch at that point. We don't add
new features in bugfixes, so there is no issue with version macros.
I think that's a great idea, if we can get all the developers to be
rigorous about making changes to the correct branch - only bugfixes
(and ALL bugfixes) to the branch, etc. It also helps with
releases, as I don't have to wade through ChangeLogs and source to
see if a new release deserves to be a major or minor release.
In fact, this is already done for the base library, but not the other
packages yet ... we need to remember to do it promptly after a release.
I would also suggest to use even numbers for releases and odd
numbers for trunk.
That is:
Lets bump the trunk version to 1.15.0 _now_. Next release will be
1.16.0 and right after its tagged, we bump trunk to 1.17.0. And so on.
I'm not really happy with this idea ... I know the Linux kernel used
to have that convention ... but most projects don't and Linux has
dropped the convention since the 2.6 kernels started coming out. It
doesn't seem particularly helpful.
Where someone wants to take a snapshot and distribute it to customers
etc, I think they really should implement their own separate version
control for this. Just saying that snapshots of trunk after version
2.10 (for instance) have version 2.11 will not help them, since they
might distribute different releases of their product with different
snapshots from the same version of GNUstep ... all of which would be
version 2.11 but all different, possibly with vendor specific
modifications which haven;t made it back into trunk yet!
Still less than ideal because we have no stable version but an
improvement over the current situation which makes it hard to
distinguish dev snapshots from final releases.
I don't think we have a policy of making unstable releases ... so all
releases are stable.
Snaphots and access via SVN are obviously unstable.
- gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers,
Richard Frith-Macdonald <=
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Hubert Chan, 2006/10/04
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/04
- Re: gnustep release numbers, Hubert Chan, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Jeremy Bettis, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
- Re: gnustep release numbers, Hubert Chan, 2006/10/04