having devel releases

[Simon Josefsson]

Moving this to gnutls-devel in case others like to chime in...

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

> Hello Simon,
>  While thinking to do some fixes for the 2.2.x branch I noticed that it is 
> quite cumbersome to maintain two releases, one stable and one development. I 
> also felt that while fixing stuff for the 2.0.x release before. That is 
> because every fix has to be commited in both and verified in both, which is 
> time-consuming and time I no longer have.
>
> Instead of that I'd propose to use a main "stable" release and branches around 
> it for big and intrusive changes. I.e a DTLS modification would be a branch 
> of the main release, which will be merged once the modifications will become 
> stable. On such big merges we could also increase the minor release number to 
> indicate such feature addition (and thus it would be that the first few 
> releases of a minor number change will be the "unstable" branch).
>
> What do you think about that? Have you also noticed this problem?

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.

Phase 1.  Stable release candidate ('master' git branch).  This means
bumping the minor release number.  We also make official "unstable"
releases from time to time, so people can test everything more easily.
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.

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.

Thus a rolling timeline will look like:

First day of Month 1:

  Stable release.

Second day of Month 1:
...
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.

Month 3:

  No new features added to 'master', they must be done on branches.
  Evaluation of release-worthiness of the how the entire package
  interacts with the new features.  Stuff that needs a lot of fixes are
  reverted and have to wait for the next cycle.  Intention is to have
  slow rate of non-important fixes here, otherwise it suggests the
  feature isn't ready yet.

First day of Month 4:
...
Last day of Month 4:

  Branch off stable release from master.  Only serious problems are
  fixed on the branch.  If there are several or non-trivial patches for
  a new feature, consider whether to pull the feature entirely because
  it is not ready yet.  Don't bother to back-port any non-security fixes
  that are discovered on the master branch, they will have to wait for
  the next cycle.

First day of Month 5:

  Stable release.

What do you think?

/Simon