Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> Stefan Monnier <address@hidden> writes:
> 
> > >> In that case, I guess we should aim for a release without the
> > >> unicode branch.  And certainly without the multi-tty branch.
> > >> (As for the tiling and lexical branches, I am not convinced I
> > >> want to make those changes.)
> > 
> > > So when do we declare "feature freeze" ?  May 1st ?
> > 
> > May 1st sounds very good to me,
> 
> 
> Did we decide on naming the next release 21.5 ?
> 
> It's simpler just to stick with 21.4 and do some real work, but if we
> must change it, who will make an effort to change 21.4 -> 21.5
> throughout the sources.

I think that 21.4 has been mentioned frequently as probably another
bug fix release, and 21.5 is "half-way" to 22.0.

Since we will need quite some time of consolidation before we can
hope to get out the new feature release, reserving 21.4 for a
possible bug fix release in case something horrible turns up that
needs immediate fixing during that time might not do harm.

And if we don't need to release a 21.4 in the mean time, the version
number jump will then perhaps be somewhat of an indicator that there
was a larger change.

It's annoying if you write things like "will be available in version
21.4 and later" in some manual and then have to admit that you were
lying.  And 21.4 has already been earmarked as a non-trunk release in
some announcements or comments.

So if we skip this bugfix release, let us also skip the number.

> To speed up things even further, should we make a pretest now?
> 
> We could announce to the pretesters that it is an early pre-test,
> but believed to be stable and ask the pretesters to actively start
> using it so we can get feedback asap.

Believed to be stable?  With several unresolved lockups and display
problems and last-minute additions?  I think that would be unfair.
"Workable" and "worth it" would be more like it.

> I suggest that we set the USE_LSB_TAG for GNU/Linux and Mac/OS for
> the first pretest; we can then enable it for more ports in the next
> pretest.

I suggest that before doing a formal pretest release, we let the last
changes shake down a few weeks among developers.

Well, at least till Mother's Day.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum