Re: stable repo

[Daniel J Sebald]

John W. Eaton wrote:
> On 24-Apr-2009, Jaroslav Hajek wrote:
>
> | so, what now? For convenience, I'll summarize my proposal once more:
> | We'll essentially have two main development repos of different speed
> | that will occassionally be synchronized (by merging, though this can
> | still be discussed).
> | 
> | Bug-fixing will primarily occur in stable repo and releases will be
> | forked from it. The stable repo will enter a "feature freeze" state
> | when a release is due to happen,
> | otherwise it will occassionally pull the new stuff from main.
> | Development of new features, improvements etc. will happen in main
> | repo, which will be unaffected by "feature freeze".
>
> I'm still trying to figure out how this will work.  The model used by
> GCC makes more sense to me.  Releases are made from the main
> development version.  When (or just before) a release, a branch is
> created for the stable release (say 3.2.0).  Eventually, at the end of
> the lifetime for the 3.2.x release series, that branch becomes
> inactive.  Development looks like this:
>
>   http://gcc.gnu.org/develop.html#timeline

This method looks pretty good.  The diagram is nice too.  From the perspective 
of people who bundle distros, they know where to go for the stable release.  
(Can we put some html links in the diagram?)

Yes, getting people to fix bugs in a stable release will be difficult, but I 
suspect there'd be a natural flow of things.  Most people who judge a bug to be 
bad or at the core of the program will be motivated to fix it.  If it isn't so 
consequential, the branch will have a short lifetime.  But I'm thinking HG is 
supposed to make things easy if a bug is fixed in the main branch and needs to 
transfered to the release branch.

Dan