[Nagiosplug-devel] RFC: making a 1.4.1 release?

Ton Voon tonvoon at mac.com
Tue Jul 5 22:55:27 CEST 2005


On 6 Jul 2005, at 00:36, sean finney wrote:

> On Tue, Jul 05, 2005 at 04:43:37PM +0100, Ton Voon wrote:
>
>> Is the CHANGES file up to date? I use that to generate the "press
>> release" that accompanies a new release.
>>
>
> i was under the impression that CHANGES was generated automatically.
> otherwise, i certainly haven't made any edits in it...
>
The ChangeLog is generated from cvs2cl, but the CHANGES file is  
manually updated (if you can work out an automatic way, I'm up for it!).

The idea is that major enhancements or breakages are put into  
CHANGES. This is the high level "what's in a new release". The  
ChangeLog is the detailed changes from comments in CVS.


>
>> Also, I'm looking for some opinions on our versioning strategy. At
>> the moment, there is the CVS HEAD branch and a r1_4 branch. I was
>> thinking that HEAD was always the latest branch, and then we apply
>> bug fixes to r1_4 and HEAD, but this is probably too much overhead.
>> There was an email some time back which suggested that we get smarter
>> with our version numbers. So I'm proposing that for the 1.4.1
>> release, we make a branch which is r1_4_1 which we only commit
>> absolutely critical bugs into (and thus into HEAD as well) and then
>> release 1.4.1.x based off this. Meanwhile, we continue committing to
>> HEAD, with a release of 1.4.x. At some point in the future, we'll
>> make the latest 1.4.x into 1.5. I think this is the way that GNU
>> coreutils is done.
>>
>
> i'm not sure i understand how doing an r_1_4_1 / HEAD combination
> would be less overhead than an r_1_4 / HEAD combination.  i'd say
> we should stay with the r_1_4 tree for bugfixes and security updates
> to the 1.4.x series of the plugins, and commit everything else to  
> HEAD.
> then, at some point we could branch off an r_1_5 tree, and when  
> that is
> stable, release that and close off r_1_4 for posterity.
>

So I think you are saying:

- stay with r1_4 and HEAD
- bugfixes and security updates to r1_4, all other development to HEAD
- create a r1_5 branch from HEAD at some point (so there is r1_4,  
r1_5 and HEAD)
- release r1_5
- close r1_4 at some point

I have two issues with this:

- all the current bugfixes you have applied would need to be  
committed into r1_4 from HEAD (I think you've been working on HEAD  
exclusively). I was trying to save you this effort!
- I'm not sure what the difference between the r1_5 branch and HEAD is

I have a (maybe oversimplified) equation in my head where "more  
branches" = "more work", so I'm trying to keep the number of branches  
to two.

Ton





More information about the Devel mailing list