Re: Stable vs. Default branch

[John W. Eaton]

On  5-Oct-2011, Jordi Gutiérrez Hermoso wrote:

| I definitely don't think we should go back to branching off for each
| stable release.
| 
| We will have to have a code freeze at some point, just before
| releasing 3.6.
| 
| This is what I propose, which is similar to what jwe has already
| suggested:
| 
|     1) We release 3.4.3 within a week or so (seems like it's ready).
| 
|     2) From now until December, we *only* patch on the stable branch
|        when we receive bug reports about the 3.4.3 release. Everything
|        else goes on default.
| 
|     3) In mid Novemberish we code freeze. Meaning, no more new
|        developments for the default branch, only bugfixes for a couple
|        of weeks.
| 
|     4) Simultaneously when we code freeze, we make a final release of
|        the 3.4 branch (3.4.4) that should include whatever bugfixes we
|        did on stable between here and November. 3.4.4 will be EOL for
|        the 3.4 series and will not receive further bugfixes.
| 
|     5) Immediately after releasing 3.4.4, we merge default to stable.
|        We spend the next two or three weeks of the freeze making RC
|        releases of the 3.6.0 version.
| 
|     6) Release 3.6 by December. Champagne, party, announcements. Part
|        of the release goals should be to make sure we have binary
|        distribution in good shape too. And we shouldn't wait until
|        December to get this working.
| 
|     7) After releasing 3.6, the code freeze is off. We continue using
|        the stable branch for patching *only* bugs reported against the
|        3.6.0 release. Everything else goes on default. And it's
|        business as usual. We make regular 3.6.1, 3.6.2... etc
|        bugfixing releases and wait for the next 3.8 code freeze (or is
|        it time for the big 4.0?).
| 
| How does that sound?

I agree with most everything here, except that whether a bug is
reported against the stable release is not the only thing that can be
used to decide whether a patch is appropriate for the stable branch.

I think that whether the bug fix goes on the stable branch should
depend on the details of the bug report and what is required to fix
the problem.  For example, if the bug report is "Octave doesn't have
Matlab-compatible handle classes", we are unlikely to put a new
implementation of that feature on the stable branch even if someone
provides a good implementation.  Or, if there is a bug in some new
feature added for 3.4.0 that requires a complex and risky fix, we
might opt to only fix it in the next major release.  Similarly, a bug
fix that breaks binary compatibility might have to be delayed.

That's why I suggested a more restrictive policy of fixing only
regressions.  But even then, we have to pay attention to whether the
fix will break binary compatibility, or the fix is too invasive and
risky.

We've made a lot of changes to the 3.4.x release series.  I'm
proposing that we try to be more conservative with the stable branch
in the future and try for more frequent major releases.

jwe