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

sean finney seanius at seanius.net
Tue Jul 5 16:38:25 CEST 2005

On Tue, Jul 05, 2005 at 04:43:37PM +0100, Ton Voon wrote:
> Can I suggest a release in two weeks, say, Thurs 21st July, to allow  
> any other fixes to be thrown in? I haven't been working on the  
> plugins recently, but I've got a bit of time soon so I'll try some  
> builds. I noticed someone had dropped in a new testing suite which  
> I'd like to commit.

sounds good to me.

> 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...

> 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.

On Tue, Jul 05, 2005 at 11:33:59PM +0200, Andreas Ericsson wrote:
> If this is the case and the np_runcmd() framework is to go in, I'd 
> strongly suggest downloading the latest fixes for those from 
> http://oss.op5.se/nagios

i'd vote against including this in a 1.4 series, since we'll be doing
some fairly active work with it in the near future.

> The package is called "op5plugins.tar.gz" (I'll upload a new one 
> tomorrow or so, with lots of other fixes as well).

i grabbed a tarball shortly before you left for vacation, but haven't
had the time to generate a diff against HEAD.  if you could do me
the favor of doing so, it'd be very helpful.

> evaluation code I wrote when I was discussing parallell execution with 
> whoever it was made it extremely fast, flexible and easy to the point of 
> being scary to write tests for. It's got a cool name too. I'll spam the 
> plugin-devel list when it's ready.

looking forward to it...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20050705/59985366/attachment.sig>

More information about the Devel mailing list