Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > I obviously agree since I called for a feature freeze a few weeks
> > (months?) back already.
> 
> IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> not to release from the branch anymore.

Why is that ?
Even if we feature freeze it now, 21.4 will not be out before the end
of 2003.  I.e. long after 21.3.

> > I also think that 21.2 should have been taken
> > from the trunk rather than from the RC branch and same thing for 21.3.
> 
> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

Rather I suggest that we don't have the manpower to have several
active branches at the same time and do a good job with it.
So if we wanted 21.2 to be a really good bug-fix release, we should
have concentrated on bug-fixing while keeping it on the trunk so
that everyone was working on bug-fixing exclusively.

> > As Dave has explained the bug-fix release 21.3 will still be riddled
> > with bugs
> FWIW, I think ``riddled with bugs'' is a grave exaggeration.

It all depends on what you consider as a bug, so I stand by my claim
that it will be riddled with bugs.  Most of them are not of the kind
that segfault and most of them cannot be trivially fixed (i.e.
fixed without a significant risk of introducing other bugs) so even if
we spend another 10 years on "bugfixing" the RC branch, those bugs
will still be there (even tho they might have already been fixed on the
trunk months ago).

> > Maybe it will be a bit
> > more stable from one particular point of view because it doesn't use any
> > new code that might introduce new bugs, but I'm definitely not convinced
> > that it outweighs the number of unfixed non-trivial bugs.
> 
> So do you really think that introduction of significant new features 
> doesn't destabilize Emacs?
> 
> That is, do you suggest to skip branch releases because they are not more
> stable _in_principle_, or just because we are too inept to make them
> significantly more stable?

They are only more stable in cases where there really is a significant
new feature that destabilizes the code base.  E.g. the new redisplay in
Emacs-21, or a unicode-based internal encoding for Emacs-22.
The kinds of changes that took place on the trunk since Emacs-21.1
don't justify the burden of branch-releases.


        Stefan