Re: Release planning (was: Re: Status report)

From: Jonathan Gardner <jgardner(at)jonathangardner(dot)net>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release planning (was: Re: Status report)
Date: 2004-07-13 22:08:35
Message-ID: 200407131508.35529.jgardner@jonathangardner.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday 13 July 2004 08:52 am, Jan Wieck wrote:
>
> I think in the future we have to force all large features, those that
> probably need more than 6 months of development time, to be properly
> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>

Take my opinion with a grain of salt, as I'm young and don't have much
experience with large, super-stable C projects.

However, looking at how the Linux community handles it, I think we can
borrow a lot of concepts from them.

Let's seperate out into two different communities: Stable and Dev.

The stable folks only want patches when necessary. They don't want new
features - they don't use them. They don't want anything but security or
stability patches. They don't want to be forced to upgrade.

New major versions are moved into the stable community, but they don't
replace old versions. No one ever says "upgrade or else!" Each major
version is kept by interested parties and patched as needed. They never
die, but are abandoned.

The dev community wants to try out all kinds of things. They aren't running
production code, so they can risk losing data. They don't have to be so
sensitive about backwards compatibility and reliability and security.

In the dev community, there is the main branch with all the accepted
features. When people feel it is time for a new major version, they spend
all their effort stabilizing that main branch. When it is finally stable,
they create a new major version and hand it off to the stable community.

People keep their own versions of postgresql in the dev community. These
compete with each other. For instance, if Tom and others don't feel like a
feature should go into the main dev branch, that doesn't mean that Bruce
won't put it in his own version and encourage people to develop against
that. When Bruce can prove that it is a useful feature and it works and is
stable enough, he will work on getting it in the main dev branch.

I know this isn't the way things have been done. I know that one of the
arguments against proposals like this is that it seperates out our pool of
developers. Yes, it will do that. But it will also open up development to
more people and more experimentation. Maybe in the end, we will have a
stable and dev community that is larger than the entire community we have
now.

--
Jonathan Gardner
jgardner(at)jonathangardner(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-07-13 22:15:54 Re: Proposal for detecting encoding mismatch in initdb
Previous Message Marc G. Fournier 2004-07-13 22:05:55 Re: Release planning (was: Re: Status report)