Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning <rlb@defaultvalue.org>]

"Eli Zaretskii" <eliz@gnu.org> writes:

> The way it worked until now was that if a decision was made to release
> the version X.N from a branch, the version number on the trunk was
> bumped up to X.N+1.50.  This involves running "M-x set-version RET"
> from admin.el.

So the presumption was that there won't be more than about 50 bugfixes
before the next "primary release".  I suppose that has been true
historically speaking with respect to the Debian packages, though the
three number versioning scheme would avoid the whole concern.

To a large extent how many bugfix releases we could make in a year or
so will depend on how the developers want to handle the "bugfix only"
testing process.  Will it be the same process as for a "bigger"
release, or can it be handled differently since the changes allowed
are much more restricted?

A related question is what relevance/relationship (if any) should the
Debian release process have?

(In Debian, we normally release a new package as soon as we have a
 fix, it goes to unstable, and then it waits there for a time.  If
 "nothing goes wrong" with it or anything it depends on during that
 time, then that package migrates to testing for eventual inclusion in
 our next stable release.)

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4