Re: Release planning (was: Re: Status report) - Mailing list pgsql-hackers

From Jonathan Gardner
Subject Re: Release planning (was: Re: Status report)
Date
Msg-id 200407131508.35529.jgardner@jonathangardner.net
Whole thread Raw
In response to Release planning (was: Re: Status report)  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Release planning (was: Re: Status report)  (Rod Taylor <pg@rbt.ca>)
List 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@jonathangardner.net


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Release planning (was: Re: Status report)
Next
From: Tom Lane
Date:
Subject: Re: Proposal for detecting encoding mismatch in initdb