On Tuesday 17 January 2006 08:04 am, Chris Cannam wrote:
> I hereby declare CVS HEAD officially soft-frozen (like a delicious
> Mövenpick ice cream) in preparation for the forthcoming release, which

Like a what?!  Nevermind, I guess it's obvious to all rightpondians.

> unless anyone strenuously objects, I propose we number "1.2.3".

How about 8.6.7.5.3.0.9?  No?

Why the .3?  I can see skipping .1.x as a release we just never actually got 
around to releasing, but should have, but I'm curious what you're thinking on 
this .x.3 bit.

> Bugs at priority 9 must be dealt with (either fixed or mitigated
> sufficiently to reduce their priority).

I do have some new priority 9 bugs coming, and we should try to get them 
knocked out.  We can argue about that once I have sat down to document them 
in a pointed way, which I will do today.

> I suggest that we make the first release candidate at the end of this week,
> and aim to have relatively few before the 1.2.3 release.  We then open a
> CVS branch for fixes on the release, and make further releases from there
> during the next six months while doing major feature work in HEAD. 
> Alternatively, we can keep HEAD for stable releases while doing features in
> "experiments" or elsewhere -- what do you think?  I'd go for the former,
> except that I have a suspicion nobody might test the fixes if they're on a
> branch.

Mostly nobody will test fixes if they're in any kind of CVS at all, so I like 
the idea of making point release tarballs.  Since the details of where we 
keep them won't matter to end recipients of these tarballs, then I vote for 
keeping HEAD for major work, and maintaining the bug-fix of the last release 
in a branch.  We could probably create the first such branch now, and start 
using it, then merge rg-experiments into HEAD and stop using rg-experiments.  
Probably documenting all of what goes where in some kind of roadmap document.

We should do whatever we can to encourage package maintainers to pick up these 
point releases, and get them into their respective systems in a timely 
fashion too.  They won't be used to having to look out for new releases from 
our project, so we might want to send out a form letter explaining what's up.  
Maybe send one now describing our broad intent, and then send out a note with 
each bug fix point release encouraging them to pick it up and get it into 
their system, and into users' hands.  So next go we're not still dealing with 
things like the 1.0 timer bug a year on.

-- 
D. Michael 'Silvan' McIntyre  ----   Silvan <[EMAIL PROTECTED]>
Linux fanatic, and certified Geek;  registered Linux user #243621

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to