stable branch release policy [was Re: Possible bug in intersect]

[Carlo de Falco]

On 12 Apr 2009, at 14:19, Jaroslav Hajek wrote:

>>
>> Hi,
>>
>> It seems this bug was introduced inbetween releases 3.0.3 and 3.0.4  
>> by the
>> following changeset:
>>
>> hg log -r 7920
>> changeset:   7920:e56bb65186f6
>> user:        Jaroslav Hajek <highegg at gmail.com>
>> date:        Wed Jun 25 22:11:07 2008 +0200
>> summary:     improve set functions for Matlab compatibility
>>
>> so the question I have is, is there a "bug-fixes only, no new  
>> features"
>> policy for the "stable" branch?
>
> Sort of. It depends on your view of bug - some users consider
> incompatibility with Matlab as a bug.

Yes, you are right, often incompatibilities are regarded as bugs.
In that case I'd say this patch is OK to be included in the stable  
branch.
If compatibility is important we might want to include a check on the  
input
arguments to make sure that they are vectors or matrices with the same  
number
of rows as is required by Matlab.
If you think this make sense I'll prepare a changeset.

> Maybe there was also some bug
> fixed by that changeset. I think there were more such "bugs" addressed
> between 3.0.3 and 3.0.4.
> I think the correct policy would be *regressions only*, as has been
> suggested by John, but I don't think that's what most users expect.
> That would likely require more frequent stable branches.

what exactly does *regressions only* mean?

>> Now, this particular bug is probably to be considered minor as  
>> compared to
>> the one in "load -ascii" so I'm not sure whether it is worth a 3.0.6
>> release,
>> but, as it is found in an m-file, maybe a warning about the bug and  
>> a link
>> to the 3.0.3 version of the set scripts on the web page would  
>> suffice?
>>
>> As an other alternative to new releases in the stable branch, to  
>> fix bugs in
>> m-files and DLD functions maybe a "bugfix" package in Octave-Forge  
>> could be
>> used?
>>
>
> No problem. Both suggestions sound OK to me.

all 3 solutions are OK for me as well, whichever is chosen in the end  
I am available to help.
>
>> Sorry if my suggestions sound stupid, I was just trying to think of  
>> a way to
>> keep the number of bugs in the stable branch a monotone non- 
>> increasing
>> function of the release number while requiring as little effort on
>> developers like Jaroslav whos precious time is better spent on  
>> improving the
>> development version.
>
> "non-increasing" probably corresponds to the "regressions only"
> strategy, which would be OK with me. But I don't think that works
> together with one major release per 16 months (since 3.0.0).
> My suggestion was to do a major release in November, after 3.0.3 when
> I saw the gap between stable and development sources becoming too big,
> but most others reckoned there was not enough new features.
> I don't really care that much about the stable releases, because I
> work almost exclusively with the development version. To be precise,
> I'm fine spending a bit of time on them (like doing the tarballs,
> maintaining the archive etc) but I'm not probably the proper one to
> decide what should be done here.
> What I'd like to follow in the future is the regressions-only
> politics, as suggested by John.

My ideal of a stable release is something well tested enough so that  
developers don't
need to spend too much of their time fixing it often but close enough  
to the development sources
so that feedback from users can still be useful..
Leaving this much time between releases is good with respect to the  
former
(except for 3.0.4 which I agree was just an unvoidable accident).
Maybe producing more snapshots (and maybe call them a "testing"  
release) could  help with the latter?
Many users will never download from VCS or even will just use only  
binary packages but still are able
to provide helpful feedback...

c.