On 4/28/07, Simon Riggs <simon@2ndquadrant.com> 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