policy for release branch

[Jaroslav Hajek]

hi,

while I realize it's mainly up to me (since I'm doing the job), I want
to initiate a discussion about the topic.

When a release is branched, what patches can go into the release
branch? Unoficially, it should be bugfixes and docfixes, but this
specification is still vague. Is missing Matlab
functionality/compatibility a bug?

I think there was also a proposal to only fix regressions; but this
doesn't work well when new & buggy features come out with a major
release - surely we don't want to leave them buggy until another major
release.

Another point is about not breaking the binary interface between minor
releases; this has some merit w.r.t. packages compatibility; however,
what if an important bugfix is created that breaks the interface?
Should it be left out? Or adapted? Who will do it?
Speaking about this, how does one tell whether the change breaks the
binary compatibility? Modifying methods is sure; what about adding new
ones? What about changing classes that are not marked as API - is that
OK?

Wow, what a lot of questions. Before attempting to answer some, here's
a major thesis: *OCTAVE CAN'T COMPETE WITH MATLAB IN TERMS OF
STABILITY*. I really mean it - look how every major release introduces
a plethora of new bugs; sometimes new bugs pop up even in minor
releases. It's not surprising - Mathworks probably has paid testers,
long testing cycle and much stricter development rules and likely a
large test suite. Surely Matlab has also bugs, but they don't get into
a release that easily. So, Octave just can't compete with that.

Where it *can* compete, is that most reported bugs are fixed within a
week, often just a day or two. Now this is, on the contrary, something
Matlab can't compete with - you can get a fix very fast, or even an
improvement or a new feature. This is, however, only true for that
relatively small number of users compiling Octave from sources. Those
who use, say, packages from a Linux distro, are limited by releases of
Octave and package updates in the distro. It would be surely nice if
those users experienced, at least partially, the advantages of the
fast bugfixing/development pace of Octave. The problem is that this
clashes with some of the above policies: if a fix breaks binary
compatibility, you'll need to wait for a major release to get it.
Maybe you don't care about the binary compatibility, and you're fine
with reinstalling packages; still, you have to wait. Is that an
acceptable price for such a policy?

I guess it all comes down to the question how often the major/minor
releases are. Anyone can probably wait 6 weeks for an important bug
fix; will anyone wait 6 months?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz