Gabriel M. Beddingfield wrote:
> Hi guys,
>
> With the 0.9.4 release coming very soon... I was thinking about the major 
> changes planned for 0.9.5 (transport, fx-fun, jackMidi).  In addition, it's 
> been 
> (what?) 3 years between 0.9.3 and 0.9.4.  And that included some major 
> changes. 
>   In light of these, I would like to make two suggestions:
>
> Proposal #1:  After releasing 0.9.4, create a 0.9 branch for bug fixes.  
> Trunk 
> will become 0.10.x.  Releases 0.9.5, .6, .7, etc. would only be bug fixes for 
> 0.9.
>
>   
I don't see the advantage here.. why we should break with the old 
numbering? Switching to 0.10
is a good idea (because of the major changes ( and not to forget, a new 
team)), but i suppose people would be less confused when the patch 
releases for 0.9.4 are numbered 0.9.4.x , like in all prior versions.
> Proposal #2:  Try for shorter release cycles.  Allow a short period of time 
> (somewhere between 2 and 6 weeks) for new features.  Freeze until all the 
> bugs 
> are worked out (or backed out).  Release when stable.  Rinse.  Repeat.  (This 
> is 
> how the Linux kernel is currently doing it.)
>
>   
Definitely true. I think that was the biggest problem with 0.9.4 - too 
much changes in one release..
I like the kernel development model a lot, so i would be pleased to do 
it this way :)
What about focusing on one major change per release (say either 
jack-midi or features from the sample-fun branche) ?
That would allow us to test the code more intensive and make it easier 
to pin down a problem to a specific change.
Just a thought..

-Sebastian

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel

Reply via email to