having devel releases

[Nikos Mavrogiannopoulos]

On Monday 17 December 2007, Simon Josefsson wrote:

> Yeah, it is problematic to maintain several branches... I think a good
> solution is to never spend time on back-porting anything except for
> security problems, and to make sure we have speedy new stable releases
> so that important non-security fixes don't get delayed.
>
> What do you think about this approach?
> Phase 0.  Chaotic development.  Separate branches, e.g., for new
> features like DTLS, PKCS#11.  Releases could be made from this branch if
> necessary, and to get feedback from testers.  No coordination with
> anyone is necessary for this.  Anyone can take the lead to implement
> some feature and make releases.

So (to make it clear to me) there would be several branches:
gnutls_2_2_x_with_dtls
gnutls_2_2_x_with_pkcs11
gnutls_2_2_x==HEAD

> Phase 1.  Stable release candidate ('master' git branch).  This means
> bumping the minor release number. 

So the next stable would be 2.3.x under this scheme?

> We also make official "unstable" 
> releases from time to time, so people can test everything more easily.

Named by the name of the branch?

> This is loosely coupled with the timing of the stable branch, we only
> add things from the chaotic development step during the first two months
> after a stable release.  If the feature requires a lot of fixes after
> that time, it is probably not ready, and should be removed from the
> stable release candidate branch.

What I noticed in the changes I did last months, is that majority of the 
additions to the code were small bug fixes, and small improvements. Those 
shouldn't need to go to a separate branch or wait for the chaotic development 
to become ordered. They could be commited directly to the (stable) say 
gnutls_2_2_x branch, and released regularly.

I'd propose, as an addition to your proposal, to have different branches for 
big changes as you mentioned, but keep the small (and unintrusive) changes 
and additions to the main (stable) branch. So something like, say, the fix 
you did to certtool for unlimited size of certificate chains, wouldn't 
require a full release cycle, or a wait for a DTLS branch (if any) to 
stabilize - which might take several months.

> Phase 2.  Stable branch (gnutls_x_y_z).  Released every 4 months with
> one months of testing were nothing is changed except for critical (or
> security? to avoid back-porting) bugs.  Once released it is never
> updated except for security bugs.  The intention is to forget about the
> branch once it has been released, and avoid spending time on the boring
> back-porting of fixes.

This is unavoidable since bug fixes will need to be backported eventually if 
they are over some level of importance. 

> Last day of Month 2:
>   Pull in things from chaotic development branches to 'master'.  Minor
>   projects is directly added to 'master'.  Make releases (possibly
>   automated), early testing.

So the master will be unstable like what we have now? If it is unstable I 
think it might be better not to cope with timetables. We could have a new 
release once an "unstable" new branch has reached a testing level. This will 
avoid having slow-paced branches to stall releases and we can take our time 
for big changes. (I currently can only work on a very slow-paced way thus I'd 
avoid any timetables).

regards,
Nikos