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
Ian@Holsman.net
|