Re: The future of 0.3
sounds good to me. if you can make sure the BUGS.txt is highlighted on the release page with a big pointer to describe that there are fundamental issues in this release, so we can set people's expectations accordingly. On 30/06/2009, at 2:04 PM, Jonathan Ellis wrote: With 0.3.0 voted in (the mentors technically have the last word, but let's assume it does get approved :), we should think about the future of the 0.3 branch. Fundamentally 0.3 has issues (see BUGS.txt) and fixing those issues would turn it into 0.4, so I see the 0.3 maintenance mission as very limited in scope. It's there to show we CAN release and to give non-developers a stable branch to use until we're done breaking things. :) I'm a huge fan of the postgresql model for database release management. New features go into major versions (8.3, 8.4, etc.) and maintenance releases (8.4.1, 8.4.2, etc.) are only for bug and security fixes. That's the only way to stay sane IMO; once you start trying to do things like backport new shiny features you WILL have regressions. And stable branches are all about NOT having those. :) So I propose fixing bugs but otherwise doing the minimum possible to disturb things in 0.3 until 0.4.0 is out, and encouraging people to migrate to that quickly when it is. -Jonathan -- Ian Holsman i...@holsman.net
Re: The future of 0.3
On Mon, 2009-06-29 at 23:04 -0500, Jonathan Ellis wrote: So I propose fixing bugs but otherwise doing the minimum possible to disturb things in 0.3 until 0.4.0 is out, and encouraging people to migrate to that quickly when it is. I think we should consider taking that a step further and just leave 0.3 completely as-is once it's been released. Unless there is someone motivated to write a migration utility (I'm not), 0.3.0 won't be upgradeable, and 0.4.0 should be along reasonably soon after. It would be better to put our efforts into 0.4.0 than to encourage people to use 0.3.0 for anything serious. -- Eric Evans eev...@rackspace.com
The future of 0.3
With 0.3.0 voted in (the mentors technically have the last word, but let's assume it does get approved :), we should think about the future of the 0.3 branch. Fundamentally 0.3 has issues (see BUGS.txt) and fixing those issues would turn it into 0.4, so I see the 0.3 maintenance mission as very limited in scope. It's there to show we CAN release and to give non-developers a stable branch to use until we're done breaking things. :) I'm a huge fan of the postgresql model for database release management. New features go into major versions (8.3, 8.4, etc.) and maintenance releases (8.4.1, 8.4.2, etc.) are only for bug and security fixes. That's the only way to stay sane IMO; once you start trying to do things like backport new shiny features you WILL have regressions. And stable branches are all about NOT having those. :) So I propose fixing bugs but otherwise doing the minimum possible to disturb things in 0.3 until 0.4.0 is out, and encouraging people to migrate to that quickly when it is. -Jonathan
