public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dawid Kuroczko <[email protected]>
To: PostgreSQL-development <[email protected]>
Subject: Re: Feature freeze progress report
Date: Sun, 29 Apr 2007 13:43:58 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

On 4/28/07, Simon Riggs <[email protected]> wrote:
> > I think the community has to come up with ideas on how to accomplish this.
> My thinking is to move to a two stage release process: Do one
> "production" release annually, and one "dev" release at the 6 month
> mid-point. That way each new release contains a manageable number of new
> features and we have a realistic chance of integrating them
> successfully. Support companies would then have the option to support
> both releases, or just the main production release. Leading edge users,
> of which we have many, would then benefit from more frequent additional
> features.

This would mean we would have to have a very well tested upgrade path
for odd releases (8.2 -> 8.4).

Also it probably would mean that analytical functions or recursive queries
should be postponed until 8.5 (as they didn't end up inside 8.3, and 8.4
would be "stable" release).

I think that with introducing stable/devel version we are risking that devel
versions will be less used in production environments (meaning less testing)
and as a result they can lengthen the development cycle.  Currently every
release is stable, therefore we don't accept "experimental patches" unless
they are really good idea.  Then there is beta sequence, and then a stable
release.  With introducing dev release, we give green light to more
"experimental"
patches, and then devote dev release as a ripening period for them (equivalent
of current pre-releases, I imagine).  And then we release stable relese (without
"experimental" patches; experimental patches are postponed until devel release,
and devel release twice the number of experimental patches).

I think we should not go into stable/devel release cycle without carefully
thinking if it will serve us good.  I am afraid this will make many people
stick with stable releases and will make upgrades harder (do you remember
how hard it was to go from Linux 2.2 to 2.4, and from 2.4 to 2.6?).

  Regards,
      Dawid

view thread (98+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Feature freeze progress report
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox