* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 19:29 ` Rob Browning
@ 2004-09-29 20:09 ` Stefan Monnier
2004-09-29 20:22 ` Jérôme Marant
` (4 subsequent siblings)
5 siblings, 0 replies; 109+ messages in thread
From: Stefan Monnier @ 2004-09-29 20:09 UTC (permalink / raw)
Cc: Kim F. Storm, emacs-devel, rms, J?r?me Marant, Miles Bader
> The only problem I can see with that approach (though it might not
> matter to you upstream) is that it makes the eventual version number
> of the more substantial upstream development releases a moving target.
As I said, I have no interest in discussing revision numbers.
If you feel like naming them 2.1, then 876.23.56.88, and the next one Toby,
that's perfectly fine with me. Others here will probably disagree, but in
any case I think most such discussions are wastes of time, because it's
really not nearly as important as it's made out to be.
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 19:29 ` Rob Browning
2004-09-29 20:09 ` Stefan Monnier
@ 2004-09-29 20:22 ` Jérôme Marant
2004-09-30 0:53 ` Luc Teirlinck
2004-09-30 0:09 ` Miles Bader
` (3 subsequent siblings)
5 siblings, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-09-29 20:22 UTC (permalink / raw)
Cc: Kim F. Storm, emacs-devel, Stefan Monnier, rms, Miles Bader
Selon Rob Browning <rlb@defaultvalue.org>:
> So while I don't have any special attachment to the X.Y.Z numbering
> scheme, it's at least one way to fix both those problems.
It brings some consistency to version numbering at least. If noone
objects (Stefan won't :-), we'll adopt this scheme.
Cheers,
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 20:22 ` Jérôme Marant
@ 2004-09-30 0:53 ` Luc Teirlinck
2004-09-30 1:25 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Luc Teirlinck @ 2004-09-30 0:53 UTC (permalink / raw)
Cc: rms, emacs-devel, monnier, storm, rlb, miles
Jerome Marant wrote:
Selon Rob Browning <rlb@defaultvalue.org>:
> So while I don't have any special attachment to the X.Y.Z numbering
> scheme, it's at least one way to fix both those problems.
It brings some consistency to version numbering at least. If noone
objects (Stefan won't :-), we'll adopt this scheme.
After grepping for `emacs-version', it appears that changing the
current convention would require checking a surprisingly *huge* amount
of code. A non-trivial amount of code will probably have to be
rewritten. version.el definitely would have to be rewritten. This is
a small file. But it would then in turn force rewriting all kind of
other stuff, spread all over the place. Many third party packages may
get broken, as they tend to check for emacs-version a lot and rely on
the current conventions.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 0:53 ` Luc Teirlinck
@ 2004-09-30 1:25 ` Miles Bader
2004-09-30 15:40 ` Robert J. Chassell
2004-09-30 1:56 ` Rob Browning
2004-09-30 9:36 ` Kim F. Storm
2 siblings, 1 reply; 109+ messages in thread
From: Miles Bader @ 2004-09-30 1:25 UTC (permalink / raw)
Cc: jerome.marant, rms, emacs-devel, monnier, storm, rlb
Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge* amount
> of code. A non-trivial amount of code will probably have to be
> rewritten.
Huh? Why? Emacs already uses three-component version numbers, it's
just that nobody ever seems to use the last one except for setting it to
"50" in CVS. Can you point out an example of code that would have to be
rewritten? To my knowledge, about 99.9% of version-checking code does
simple string-compares to look at the first 2 digits.
An interesting idea might be to make `emacs-minor-version' a
floating-point number, e.g. for 21.4, emacs-minor-version is 4, but for
21.4.1, it would be 4.1. I'll bet that would make a lot of code `just
work'.
-Miles
--
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 1:25 ` Miles Bader
@ 2004-09-30 15:40 ` Robert J. Chassell
2004-09-30 17:02 ` Rob Browning
0 siblings, 1 reply; 109+ messages in thread
From: Robert J. Chassell @ 2004-09-30 15:40 UTC (permalink / raw)
> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge*
> amount of code.
Can we not just increment the last component of the existing
three-component version number?
Right now, emacs/lisp/version.el says
(defconst emacs-version "21.3.50" "\
Version numbers of this version of Emacs.")
Could not that be incremented to "21.3.51" for a bug fix release?
(Or better yet, have the release be "21.4.0" and the bug fix releases
be "21.4.1", "21.4.2", etc; this would enable us to continue to
specify a 50 for the next version's CVS trunk and a 90 for the
pretest, as in "21.4.50". ... Of course, I presume fewer than 50 bug
fix releases before a minor or major version number increment .... :)
Let's refer to the existing third component as the tertiant, with its
adjective being `tertiary'. If for whatever reason, we need to
specify a variable then it would be the third of this sequence;
emacs-major-version
emacs-minor-version
emacs-tertiary-version
as in
(defconst emacs-tertiary-version
(progn
(string-match "\\(^[0-9]+\\.\\([0-9]+\\).\\([0-9]+\\)\\)" emacs-version)
(string-to-int (match-string 3 emacs-version)))
"Version number of the third component of emacs-version.")
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:40 ` Robert J. Chassell
@ 2004-09-30 17:02 ` Rob Browning
2004-09-30 19:32 ` Robert J. Chassell
0 siblings, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-09-30 17:02 UTC (permalink / raw)
Cc: emacs-devel
"Robert J. Chassell" <bob@rattlesnake.com> writes:
> Let's refer to the existing third component as the tertiant, with its
> adjective being `tertiary'. If for whatever reason, we need to
> specify a variable then it would be the third of this sequence;
>
> emacs-major-version
> emacs-minor-version
> emacs-tertiary-version
FWIW this has also been called the "micro" version in other projects,
i.e. emacs-micro-version.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 17:02 ` Rob Browning
@ 2004-09-30 19:32 ` Robert J. Chassell
0 siblings, 0 replies; 109+ messages in thread
From: Robert J. Chassell @ 2004-09-30 19:32 UTC (permalink / raw)
Rob Browning <rlb@defaultvalue.org> wrote
> emacs-major-version
> emacs-minor-version
> emacs-tertiary-version
FWIW this has also been called the "micro" version in other projects,
i.e. emacs-micro-version.
That is OK with me. It is not a big deal.
The reason I think in terms of `tertiants', is that the base of each
component in a version number may be different.
Dates and times use months, days, hours, minutes, seconds, and
(occasionally) tertiants. These components are not all numbered in
base 12 (as they ought to be). Whenever I think in terms of `micro',
and `nano', I think of components using the same base, like
microseconds and nanoseconds.
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 0:53 ` Luc Teirlinck
2004-09-30 1:25 ` Miles Bader
@ 2004-09-30 1:56 ` Rob Browning
2004-09-30 7:42 ` Jérôme Marant
2004-09-30 9:36 ` Kim F. Storm
2 siblings, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-09-30 1:56 UTC (permalink / raw)
Cc: jerome.marant, rms, emacs-devel, monnier, storm, miles
Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge*
> amount of code. A non-trivial amount of code will probably have to
> be rewritten. version.el definitely would have to be rewritten.
> This is a small file. But it would then in turn force rewriting all
> kind of other stuff, spread all over the place. Many third party
> packages may get broken, as they tend to check for emacs-version a
> lot and rely on the current conventions.
Ahh. I wondered about that.
OK, well, as I mentioned, I'm not set on any particular approach. I
just wanted to bring up the release issues before deciding on a
process. Of course, none of this has to be resolved immediately. It
can certainly wait until 21.4 is ready.
Thanks
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 1:56 ` Rob Browning
@ 2004-09-30 7:42 ` Jérôme Marant
0 siblings, 0 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 7:42 UTC (permalink / raw)
Cc: Luc Teirlinck, rms, emacs-devel, monnier, storm, miles
Quoting Rob Browning <rlb@defaultvalue.org>:
> Ahh. I wondered about that.
>
> OK, well, as I mentioned, I'm not set on any particular approach. I
> just wanted to bring up the release issues before deciding on a
> process. Of course, none of this has to be resolved immediately. It
> can certainly wait until 21.4 is ready.
No, if there is any problem, it shall be fixed in the trunk ASAP because
we don't want this part of the code to divert from the trunk in a bugfix
release.
Otherwise, we need to adopt another scheme.
Cheers,
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 0:53 ` Luc Teirlinck
2004-09-30 1:25 ` Miles Bader
2004-09-30 1:56 ` Rob Browning
@ 2004-09-30 9:36 ` Kim F. Storm
2004-09-30 14:11 ` Eli Zaretskii
2 siblings, 1 reply; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 9:36 UTC (permalink / raw)
Cc: jerome.marant, rms, emacs-devel, monnier, rlb, miles
Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Jerome Marant wrote:
>
> Selon Rob Browning <rlb@defaultvalue.org>:
>
> > So while I don't have any special attachment to the X.Y.Z numbering
> > scheme, it's at least one way to fix both those problems.
>
> It brings some consistency to version numbering at least. If noone
> objects (Stefan won't :-), we'll adopt this scheme.
>
> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge* amount
> of code. A non-trivial amount of code will probably have to be
> rewritten. version.el definitely would have to be rewritten.
I don't see why.
CVS emacs currently has emacs-version 21.3.50.12 or similar, so
what need changing?
> This is
> a small file. But it would then in turn force rewriting all kind of
> other stuff, spread all over the place. Many third party packages may
> get broken, as they tend to check for emacs-version a lot and rely on
> the current conventions.
If code usese emacs-version to check for what features are available then
a) that code is broken in the first place if it cannot handle the
CVS emacs version string format, and
b) such code should only look at the X and Y components of the
version number.
The rationale for b) is that the Z component differentiates BUG FIX
releases, so from 3rd party packages point of view, X.Y, X.Y.0 and
X.Y.7 are to be considered equivalent functionality-wise.
So I think X.Y.Z would work fine.
BTW, what is currently really broken in CVS emacs is that
emacs-minor-version is 3 -- it should be 4.
Since we use X.Y.50 and X.Y.90 for cvs and pretest versions
for X.(Y+1), a better approach would be:
(defconst emacs-minor-version
(if (and (string-match "^[0-9]+\\.\\([0-9]+\\)\\.\\([0-9]+\\)" emacs-version)
(>= (string-to-int (match-string 2 emacs-version)) 50))
(1+ (string-to-int (match-string 1 emacs-version)))
(string-to-int (match-string 1 emacs-version)))
"Minor version number of this version of Emacs.
This variable first existed in version 19.23.")
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 9:36 ` Kim F. Storm
@ 2004-09-30 14:11 ` Eli Zaretskii
2004-09-30 14:32 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 14:11 UTC (permalink / raw)
Cc: jerome.marant, rlb, emacs-devel
> From: storm@cua.dk (Kim F. Storm)
> Date: Thu, 30 Sep 2004 11:36:33 +0200
> Cc: jerome.marant@free.fr, rms@gnu.org, emacs-devel@gnu.org,
> monnier@iro.umontreal.ca, rlb@defaultvalue.org, miles@gnu.org
>
> CVS emacs currently has emacs-version 21.3.50.12 or similar, so
> what need changing?
I might be missing something, but don't we assume somewhere that
X.Y.Z.NN version signals a pretest, while X.Y.NN signals a released
version?
Anyway, what's wrong with the current scheme that we need to abandon
it, and how does the suggested 3-component scheme improves that to a
degree that justifies additional work (to fix all those places that
will need fixing)?
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:11 ` Eli Zaretskii
@ 2004-09-30 14:32 ` Miles Bader
2004-09-30 15:02 ` Stefan Monnier
2004-09-30 15:34 ` Eli Zaretskii
2004-09-30 14:36 ` Jérôme Marant
2004-09-30 15:00 ` Kim F. Storm
2 siblings, 2 replies; 109+ messages in thread
From: Miles Bader @ 2004-09-30 14:32 UTC (permalink / raw)
Cc: jerome.marant, emacs-devel, rlb, storm
On Thu, Sep 30, 2004 at 04:11:38PM +0200, Eli Zaretskii wrote:
> Anyway, what's wrong with the current scheme that we need to abandon
> it
Because the current scheme is confusing to users. I've certainly observed
doubt as to whether a new Emacs release "means anything" (i.e. lots of new
features, or just a few random fixes) or not.
> and how does the suggested 3-component scheme improves that to a
> degree that justifies additional work (to fix all those places that
> will need fixing)?
What work? I saw a similar claim earlier in this thread, grepped around a
bit, and saw no places that seemed to care what the version looks like. No
doubt there are a few places like the maintenance scripts in admin, but
frankly if it's _only_ that, it's a silly objection -- there's certainly
somebody willing to fix those up. Lisp packages are really the place that
matters, and as I mentioned, I've seen absolutely no evidence that such a
change would have any adverse impact at all.
I think the suggestion that a third-level component >= 50 mean "development"
is a very reasonable idea to retain that distinction, and in general
following Rob's would seem to result in something that's a lot less clunky
than the current system.
-Miles
--
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:32 ` Miles Bader
@ 2004-09-30 15:02 ` Stefan Monnier
2004-09-30 15:34 ` Eli Zaretskii
1 sibling, 0 replies; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 15:02 UTC (permalink / raw)
Cc: jerome.marant, Eli Zaretskii, storm, rlb, emacs-devel
>> Anyway, what's wrong with the current scheme that we need to abandon it
> Because the current scheme is confusing to users. I've certainly observed
> doubt as to whether a new Emacs release "means anything" (i.e. lots of new
> features, or just a few random fixes) or not.
If you want that kind of clarity, then either say:
- use MAJOR.MINOR where MINOR is only incremented for bugfix releases and
MAJOR is incremented for non-bugfix releases. I.e. the next release would
then be 22.1 and unicode would be 23.1.
- Use MAJOR.MIDDLE.MINOR where the difference is that some non-bugfix
releases are deemed non-major (e.g. the next one would then be 21.4.1 and
unicode would be 22.1.1).
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:32 ` Miles Bader
2004-09-30 15:02 ` Stefan Monnier
@ 2004-09-30 15:34 ` Eli Zaretskii
1 sibling, 0 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 15:34 UTC (permalink / raw)
Cc: jerome.marant, rlb, emacs-devel
> Date: Thu, 30 Sep 2004 10:32:41 -0400
> Cc: storm@cua.dk, jerome.marant@free.fr, rlb@defaultvalue.org,
> emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
>
> What work? I saw a similar claim earlier in this thread, grepped around a
> bit, and saw no places that seemed to care what the version looks like. No
> doubt there are a few places like the maintenance scripts in admin, but
> frankly if it's _only_ that, it's a silly objection -- there's certainly
> somebody willing to fix those up.
I suspect there's more than that. E.g., the scripts we use to prepare
a release, etc.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:11 ` Eli Zaretskii
2004-09-30 14:32 ` Miles Bader
@ 2004-09-30 14:36 ` Jérôme Marant
2004-09-30 15:00 ` Kim F. Storm
2 siblings, 0 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 14:36 UTC (permalink / raw)
Cc: emacs-devel, rlb, storm
Quoting Eli Zaretskii <eliz@gnu.org>:
> Anyway, what's wrong with the current scheme that we need to abandon
> it, and how does the suggested 3-component scheme improves that to a
> degree that justifies additional work (to fix all those places that
> will need fixing)?
What scheme do you have in mind that won't clash with the current
scheme, that is, changing bugfix versions separately from trunk
versions?
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:11 ` Eli Zaretskii
2004-09-30 14:32 ` Miles Bader
2004-09-30 14:36 ` Jérôme Marant
@ 2004-09-30 15:00 ` Kim F. Storm
2004-09-30 16:33 ` Rob Browning
2004-09-30 17:37 ` Richard Stallman
2 siblings, 2 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 15:00 UTC (permalink / raw)
Cc: jerome.marant, rlb, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> From: storm@cua.dk (Kim F. Storm)
>> Date: Thu, 30 Sep 2004 11:36:33 +0200
>> Cc: jerome.marant@free.fr, rms@gnu.org, emacs-devel@gnu.org,
>> monnier@iro.umontreal.ca, rlb@defaultvalue.org, miles@gnu.org
>>
>> CVS emacs currently has emacs-version 21.3.50.12 or similar, so
>> what need changing?
>
> I might be missing something, but don't we assume somewhere that
> X.Y.Z.NN version signals a pretest, while X.Y.NN signals a released
> version?
Yes, and it is VERY confusion --- since X.Y.Z.NN is really a pretest
of X.(Y+1)
We once discussed the idea to use negative Z values for CVS and pretests,
e.g. instead of 21.3.50.NN we would have 21.4.-99.NN for CVS version
and pretests vould be 21.4.-98, 21.4.-97 etc.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:00 ` Kim F. Storm
@ 2004-09-30 16:33 ` Rob Browning
2004-09-30 17:37 ` Richard Stallman
1 sibling, 0 replies; 109+ messages in thread
From: Rob Browning @ 2004-09-30 16:33 UTC (permalink / raw)
Cc: jerome.marant, Eli Zaretskii, emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> Yes, and it is VERY confusion --- since X.Y.Z.NN is really a pretest
> of X.(Y+1)
I think that's one of the motivations for projects that have gone to
the even/odd MINOR convention given the MAJOR.MINOR.MICRO versioning
style. Then you can release as many odd-numbered versions as you
like, as long as everyone knows the convention.
Changing to that approach in guile has been fairly successful, though
there are still issues. For example, for the final tests of a
X.EVEN.0 candidate (say 1.6.0), you may not want to test something
that's actually numbered 1.5.43 in the code, and then change the
version to 1.6.0 just before making the release build. Even if that
final build has no other changes, it still hasn't been tested.
The solution I'm currently using for guile is to actually version the
final release candidate as the final release, i.e. 1.6.0, but to name
the pre-release tarfiles as guile-1.6.0rcN.tar.gz rather than
guile-1.6.0.tar.gz, and then place them on alpha.gnu.org. In all
other ways, the release candidate tarfile *is* the tarfile that will
become the final release, if no relevant bugs are found.
Actually, that's not exactly right. I'm also considering placing a
file inside the pre-release indicating that it's a pre-release and
indicating which pre-release. When a pre-release (rcN) tarfile
finally checks out and is ready to become the the final release, that
"pre-release indicator" file will just be removed without building a
new dist via tar --delete or similar.
This will still leave misleading things like "Guile 1.6.0 released."
in a pre-release ChangeLog (when it should really say "Guile 1.6.0
release candidate N.", but in my estimation that's better than
alternatives that would require another CVS commit, and building an
untested new distfile. Also, since the pre-releases will only be
uploaded to alpha.gnu.org, it seems unlikely that someone would end up
accidentally confused.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:00 ` Kim F. Storm
2004-09-30 16:33 ` Rob Browning
@ 2004-09-30 17:37 ` Richard Stallman
2004-09-30 19:39 ` Robert J. Chassell
2004-09-30 20:26 ` Kim F. Storm
1 sibling, 2 replies; 109+ messages in thread
From: Richard Stallman @ 2004-09-30 17:37 UTC (permalink / raw)
Cc: jerome.marant, eliz, rlb, emacs-devel
We once discussed the idea to use negative Z values for CVS and pretests,
e.g. instead of 21.3.50.NN we would have 21.4.-99.NN for CVS version
and pretests vould be 21.4.-98, 21.4.-97 etc.
One drawback of this idea is that the pretest version numbers are moving
towards a fixed limit of zero, which puts a bound on them. What we
really want is numbers like 21.4.-1/1, 21.4.-1/2, 21.4.-1/3, where
the pretest version numbers form series converging towards zero.
Or perhaps 21.4-1/2, 21.4-1/3, 21.4-1/4, which converge towards 21.4.
- use MAJOR.MINOR where MINOR is only incremented for bugfix releases and
MAJOR is incremented for non-bugfix releases. I.e. the next release would
then be 22.1 and unicode would be 23.1.
That would be a good scheme, I think.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 17:37 ` Richard Stallman
@ 2004-09-30 19:39 ` Robert J. Chassell
2004-10-03 1:18 ` Richard Stallman
2004-09-30 20:26 ` Kim F. Storm
1 sibling, 1 reply; 109+ messages in thread
From: Robert J. Chassell @ 2004-09-30 19:39 UTC (permalink / raw)
- use MAJOR.MINOR where MINOR is only incremented for bugfix
releases and MAJOR is incremented for non-bugfix releases.
I.e. the next release would then be 22.1 and unicode would be
23.1.
That would be a good scheme, I think.
The goal is to provide a decent program. One whose version numbers
confuse people, so they think a major upgrade is a minor bug fix, is
no good. Historically, Emacs has signified major changes with
integral number changes: version 19 was the biggest of those changes
(from a user's point of view).
Why not make more use of the three component numbering scheme we
already have and use in CVS?
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 17:37 ` Richard Stallman
2004-09-30 19:39 ` Robert J. Chassell
@ 2004-09-30 20:26 ` Kim F. Storm
2004-09-30 20:36 ` Stefan Monnier
2004-09-30 21:42 ` Andreas Schwab
1 sibling, 2 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 20:26 UTC (permalink / raw)
Cc: jerome.marant, eliz, rlb, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> We once discussed the idea to use negative Z values for CVS and pretests,
> e.g. instead of 21.3.50.NN we would have 21.4.-99.NN for CVS version
> and pretests vould be 21.4.-98, 21.4.-97 etc.
>
> One drawback of this idea is that the pretest version numbers are moving
> towards a fixed limit of zero, which puts a bound on them.
So call the CVS version 21.4.-999 and let the pretests use -998 -997 etc.
That should be enough I think (hope :-)
> - use MAJOR.MINOR where MINOR is only incremented for bugfix releases and
> MAJOR is incremented for non-bugfix releases. I.e. the next release would
> then be 22.1 and unicode would be 23.1.
>
> That would be a good scheme, I think.
I really wish we could agree on renumbering the next release from trunk to 22.1.
It is the first major release in YEARS, so it warrants a new major release number.
And it could mark the start of a new bug-fix numbering scheme:
CVS version: 22.1.-999
Pretests: 22.1.-998 ... 22.1.-1
Initial release: 22.1 (or 22.1.0)
Bug fixes: 22.1.1, 22.1.2, ...
Minor releases: 22.2, 22.3, ...
I hereby offer to make all the necessary changes!
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:26 ` Kim F. Storm
@ 2004-09-30 20:36 ` Stefan Monnier
2004-09-30 20:46 ` Jérôme Marant
2004-09-30 21:33 ` Kim F. Storm
2004-09-30 21:42 ` Andreas Schwab
1 sibling, 2 replies; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 20:36 UTC (permalink / raw)
Cc: jerome.marant, eliz, rms, rlb, emacs-devel
> CVS version: 22.1.-999
> Pretests: 22.1.-998 ... 22.1.-1
> Initial release: 22.1 (or 22.1.0)
> Bug fixes: 22.1.1, 22.1.2, ...
> Minor releases: 22.2, 22.3, ...
Counter proposal:
CVS version: 22.0.50
Pretests: 22.0.90, 22.0.91, ..., 22.0.99, 22.0.991, ...
Initial release: 22.1
Bug fixes: 22.2, 22.3, ...
Minor release = bug fix
I hereby offer to make all the necessary changes (barely any, other than
change all the references to 21.4 to say 22.1 and to change 21.3.50 to
22.0.50).
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:36 ` Stefan Monnier
@ 2004-09-30 20:46 ` Jérôme Marant
2004-09-30 21:40 ` Kim F. Storm
2004-09-30 21:33 ` Kim F. Storm
1 sibling, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 20:46 UTC (permalink / raw)
Cc: jerome.marant, rms, emacs-devel, Kim F. Storm, eliz, rlb
Selon Stefan Monnier <monnier@iro.umontreal.ca>:
> > CVS version: 22.1.-999
> > Pretests: 22.1.-998 ... 22.1.-1
> > Initial release: 22.1 (or 22.1.0)
> > Bug fixes: 22.1.1, 22.1.2, ...
> > Minor releases: 22.2, 22.3, ...
>
> Counter proposal:
>
> CVS version: 22.0.50
> Pretests: 22.0.90, 22.0.91, ..., 22.0.99, 22.0.991, ...
> Initial release: 22.1
> Bug fixes: 22.2, 22.3, ...
> Minor release = bug fix
Counter proposal (the linux way):
CVS version: 21.5.50
Pretests: 21.5.90 ...
Initial release: 22.0
Bugfix releases: 22.0.1, 22.0.2 ...
CVS version: 22.1.50
Pretests: 21.1.90 ...
Initial release: 22.2
Bugfix releases: 22.2.1, 22.2.2 ...
Nothing to change in the current code.
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:46 ` Jérôme Marant
@ 2004-09-30 21:40 ` Kim F. Storm
0 siblings, 0 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 21:40 UTC (permalink / raw)
Cc: jerome.marant, rms, emacs-devel, Stefan Monnier, eliz, rlb
Jérôme Marant <jmarant@free.fr> writes:
>
> Counter proposal (the linux way):
>
> CVS version: 21.5.50
> Pretests: 21.5.90 ...
> Initial release: 22.0
> Bugfix releases: 22.0.1, 22.0.2 ...
IMO this is even worse than the current scheme -- we could
be running a pretest with both major and minor numbers which
differs from the final release...
And traditionally, we don't use XX.0 (IIRC).
>
> CVS version: 22.1.50
> Pretests: 21.1.90 ...
> Initial release: 22.2
> Bugfix releases: 22.2.1, 22.2.2 ...
>
> Nothing to change in the current code.
Dejavu...
It seems that we run around in circles every time we discuss this issue.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:36 ` Stefan Monnier
2004-09-30 20:46 ` Jérôme Marant
@ 2004-09-30 21:33 ` Kim F. Storm
2004-09-30 21:48 ` Stefan Monnier
1 sibling, 1 reply; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 21:33 UTC (permalink / raw)
Cc: jerome.marant, eliz, rms, rlb, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> CVS version: 22.1.-999
>> Pretests: 22.1.-998 ... 22.1.-1
>> Initial release: 22.1 (or 22.1.0)
>> Bug fixes: 22.1.1, 22.1.2, ...
>> Minor releases: 22.2, 22.3, ...
>
> Counter proposal:
>
> CVS version: 22.0.50
> Pretests: 22.0.90, 22.0.91, ..., 22.0.99, 22.0.991, ...
> Initial release: 22.1
> Bug fixes: 22.2, 22.3, ...
> Minor release = bug fix
>
> I hereby offer to make all the necessary changes (barely any, other than
> change all the references to 21.4 to say 22.1 and to change 21.3.50 to
> 22.0.50).
This proposal still does not address the constant confusion (just look
at the mailing lists) about the unclear numbering of the CVS version;
IMO, the cvs version and pretests should use THE SAME minor number as
the final release -- not the minor number of previous release.
What about:
CVS version: 22.1.-999
Pretests: 22.1.-998 ... 22.1.-1
Initial release: 22.1
Bug fixes: 22.2, 22.3, ...
Minor releases = bug fix
This also allows us to have a "working" version in CVS for bug fixes /
minor releases, e.g.
22.2.-999
and run pretests for minor releases, e.g.
22.2.-998
--
Kim F. Storm http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:26 ` Kim F. Storm
2004-09-30 20:36 ` Stefan Monnier
@ 2004-09-30 21:42 ` Andreas Schwab
2004-09-30 22:16 ` Kim F. Storm
1 sibling, 1 reply; 109+ messages in thread
From: Andreas Schwab @ 2004-09-30 21:42 UTC (permalink / raw)
Cc: jerome.marant, eliz, rms, rlb, emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> And it could mark the start of a new bug-fix numbering scheme:
>
> CVS version: 22.1.-999
22.0.1
> Pretests: 22.1.-998 ... 22.1.-1
22.0.50 ...
> Initial release: 22.1 (or 22.1.0)
> Bug fixes: 22.1.1, 22.1.2, ...
>
> Minor releases: 22.2, 22.3, ...
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 21:42 ` Andreas Schwab
@ 2004-09-30 22:16 ` Kim F. Storm
2004-09-30 22:21 ` Stefan Monnier
2004-10-03 14:32 ` Richard Stallman
0 siblings, 2 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 22:16 UTC (permalink / raw)
Cc: jerome.marant, eliz, rms, rlb, emacs-devel
Andreas Schwab <schwab@suse.de> writes:
> storm@cua.dk (Kim F. Storm) writes:
>
>> And it could mark the start of a new bug-fix numbering scheme:
>>
>> CVS version: 22.1.-999
> 22.0.1
>> Pretests: 22.1.-998 ... 22.1.-1
> 22.0.50 ...
>> Initial release: 22.1 (or 22.1.0)
>> Bug fixes: 22.1.1, 22.1.2, ...
>>
>> Minor releases: 22.2, 22.3, ...
>
Or simpler:
CVS version: 22.0
Pretests: 22.0.1, 22.0.2, ...
Initial release: 22.1
Bug fixes: 22.2, 22.3
Minor release = bug fixes
And CVS version bumps to 23.0 when 22.1 is released.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 22:16 ` Kim F. Storm
@ 2004-09-30 22:21 ` Stefan Monnier
2004-10-01 16:43 ` Kim F. Storm
2004-10-03 14:32 ` Richard Stallman
1 sibling, 1 reply; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 22:21 UTC (permalink / raw)
Cc: jerome.marant, rms, Andreas Schwab, emacs-devel, eliz, rlb
> CVS version: 22.0
> Pretests: 22.0.1, 22.0.2, ...
> Initial release: 22.1
> Bug fixes: 22.2, 22.3
> Minor release = bug fixes
That's what I originally wrote and then I switched back to 22.0.50 and
22.0.90 because 22.0 bug reports would otherwise be sent to gnu.emacs.bug
rather than to emacs-pretest-bug ;-0
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 22:21 ` Stefan Monnier
@ 2004-10-01 16:43 ` Kim F. Storm
0 siblings, 0 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-10-01 16:43 UTC (permalink / raw)
Cc: jerome.marant, rms, Andreas Schwab, emacs-devel, Kim F. Storm,
eliz, rlb
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> CVS version: 22.0
>> Pretests: 22.0.1, 22.0.2, ...
>> Initial release: 22.1
>> Bug fixes: 22.2, 22.3
>> Minor release = bug fixes
>
> That's what I originally wrote and then I switched back to 22.0.50 and
> 22.0.90 because 22.0 bug reports would otherwise be sent to gnu.emacs.bug
> rather than to emacs-pretest-bug ;-0
>
We can just change the code!
- (let ((pretest-p (string-match "\\..*\\..*\\." emacs-version))
+ (let ((pretest-p (string-match "\\.0" emacs-version))
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 22:16 ` Kim F. Storm
2004-09-30 22:21 ` Stefan Monnier
@ 2004-10-03 14:32 ` Richard Stallman
1 sibling, 0 replies; 109+ messages in thread
From: Richard Stallman @ 2004-10-03 14:32 UTC (permalink / raw)
Cc: jerome.marant, schwab, eliz, rlb, emacs-devel
Or simpler:
CVS version: 22.0
Pretests: 22.0.1, 22.0.2, ...
Initial release: 22.1
Bug fixes: 22.2, 22.3
Minor release = bug fixes
Although I like the idea of negative numbers for pretests best,
this plan is also simple and clear. We could use it if the other
has some kind of problem.
That's what I originally wrote and then I switched back to 22.0.50 and
22.0.90 because 22.0 bug reports would otherwise be sent to gnu.emacs.bug
rather than to emacs-pretest-bug ;-0
We can easily change the criteria in emacs-pretest-bug
for whatever version scheme we use.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 19:29 ` Rob Browning
2004-09-29 20:09 ` Stefan Monnier
2004-09-29 20:22 ` Jérôme Marant
@ 2004-09-30 0:09 ` Miles Bader
2004-09-30 14:21 ` Eli Zaretskii
` (2 subsequent siblings)
5 siblings, 0 replies; 109+ messages in thread
From: Miles Bader @ 2004-09-30 0:09 UTC (permalink / raw)
Cc: emacs-devel, rms, Stefan Monnier, J?r?me Marant, Kim F. Storm
Rob Browning <rlb@defaultvalue.org> writes:
> So while I don't have any special attachment to the X.Y.Z numbering
> scheme, it's at least one way to fix both those problems.
I think this sounds fine, and less confusing that recent practice.
-Miles
--
P.S. All information contained in the above letter is false,
for reasons of military security.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 19:29 ` Rob Browning
` (2 preceding siblings ...)
2004-09-30 0:09 ` Miles Bader
@ 2004-09-30 14:21 ` Eli Zaretskii
2004-09-30 14:32 ` Jérôme Marant
` (3 more replies)
2004-09-30 15:59 ` Richard Stallman
2004-10-01 6:24 ` Francesco Potorti`
5 siblings, 4 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 14:21 UTC (permalink / raw)
Cc: jmarant, emacs-devel
> From: Rob Browning <rlb@defaultvalue.org>
> Date: Wed, 29 Sep 2004 14:29:20 -0500
> Cc: "Kim F. Storm" <storm@cua.dk>, emacs-devel@gnu.org, rms@gnu.org,
> Jerome Marant <jmarant@free.fr>, Miles Bader <miles@gnu.org>
>
> Imagine that 21.4 has been relased, and then imagine Jerome and I have
> made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
> that were submitted to Debian, that have been approved by the Emacs
> developers. Now imagine that you're preparing to make a new release
> from the "main" upstream development branch. What do you call it? If
> you pick 21.8 and then you're unexpectedly delayed for a month or two
> (for whatever reason), then we're in trouble if we need to make a
> bugfix release (imagine a data-destroying bug of some kind that can't
> wait). We'd need something between 21.7 and 21.8.
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.
The situation you describe, where both a branch and a trunk version
are undergoing a pretest never happened before, since Emacs
development until now assumed that we don't have enough resources to
do that, and so there was at most one pretest at a time. I'm not sure
we can change that, given the available resources.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:21 ` Eli Zaretskii
@ 2004-09-30 14:32 ` Jérôme Marant
2004-09-30 15:31 ` Eli Zaretskii
2004-09-30 14:34 ` Miles Bader
` (2 subsequent siblings)
3 siblings, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 14:32 UTC (permalink / raw)
Cc: Rob Browning, emacs-devel
Quoting Eli Zaretskii <eliz@gnu.org>:
> 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.
>
> The situation you describe, where both a branch and a trunk version
> are undergoing a pretest never happened before, since Emacs
> development until now assumed that we don't have enough resources to
> do that, and so there was at most one pretest at a time. I'm not sure
> we can change that, given the available resources.
So, are you telling that maintaing bugfix release like we proposed
is not doable because of the current numbering scheme?
If not, what do you propose?
Thanks.
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:32 ` Jérôme Marant
@ 2004-09-30 15:31 ` Eli Zaretskii
0 siblings, 0 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 15:31 UTC (permalink / raw)
Cc: rlb, emacs-devel
> Date: Thu, 30 Sep 2004 16:32:18 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: Rob Browning <rlb@defaultvalue.org>, emacs-devel@gnu.org
>
> So, are you telling that maintaing bugfix release like we proposed
> is not doable because of the current numbering scheme?
I don't understand what ``like we proposed'' means. I don't think the
current scheme disallows anything.
> If not, what do you propose?
To keep the current scheme.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:21 ` Eli Zaretskii
2004-09-30 14:32 ` Jérôme Marant
@ 2004-09-30 14:34 ` Miles Bader
2004-09-30 15:37 ` Eli Zaretskii
2004-09-30 14:55 ` Kim F. Storm
2004-09-30 15:15 ` Rob Browning
3 siblings, 1 reply; 109+ messages in thread
From: Miles Bader @ 2004-09-30 14:34 UTC (permalink / raw)
Cc: jmarant, Rob Browning, emacs-devel
On Thu, Sep 30, 2004 at 04:21:47PM +0200, Eli Zaretskii wrote:
> The situation you describe, where both a branch and a trunk version
> are undergoing a pretest never happened before, since Emacs
> development until now assumed that we don't have enough resources to
> do that, and so there was at most one pretest at a time. I'm not sure
> we can change that, given the available resources.
Um, the whole point of this thread is that more resources are on offer, for
this specific purpose.
-Miles
--
o The existentialist, not having a pillow, goes everywhere with the book by
Sullivan, _I am going to spit on your graves_.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:34 ` Miles Bader
@ 2004-09-30 15:37 ` Eli Zaretskii
2004-09-30 15:53 ` Jérôme Marant
2004-09-30 19:15 ` Robert J. Chassell
0 siblings, 2 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 15:37 UTC (permalink / raw)
Cc: jmarant, rlb, emacs-devel
> Date: Thu, 30 Sep 2004 10:34:04 -0400
> Cc: Rob Browning <rlb@defaultvalue.org>, jmarant@free.fr,
> emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
>
> On Thu, Sep 30, 2004 at 04:21:47PM +0200, Eli Zaretskii wrote:
> > The situation you describe, where both a branch and a trunk version
> > are undergoing a pretest never happened before, since Emacs
> > development until now assumed that we don't have enough resources to
> > do that, and so there was at most one pretest at a time. I'm not sure
> > we can change that, given the available resources.
>
> Um, the whole point of this thread is that more resources are on offer, for
> this specific purpose.
Like everyone else, I'm grateful for the offer, but I think you know
that it takes more to pretest a version than just administrative help
we are offered. If this is enough to be able to run 2 pretests in
parallel, I just don't know; thus ``I'm not sure'' above.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:37 ` Eli Zaretskii
@ 2004-09-30 15:53 ` Jérôme Marant
2004-09-30 16:06 ` Eli Zaretskii
2004-09-30 16:53 ` [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Rob Browning
2004-09-30 19:15 ` Robert J. Chassell
1 sibling, 2 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 15:53 UTC (permalink / raw)
Cc: emacs-devel, rlb, Miles Bader
Quoting Eli Zaretskii <eliz@gnu.org>:
> > Um, the whole point of this thread is that more resources are on offer, for
> > this specific purpose.
>
> Like everyone else, I'm grateful for the offer, but I think you know
> that it takes more to pretest a version than just administrative help
> we are offered. If this is enough to be able to run 2 pretests in
> parallel, I just don't know; thus ``I'm not sure'' above.
Why would we necessarily have to go through this pretest phase the
way it is currently done for major releases?
You look worried about being involved in such releases, but we
are proposing to be delegated to perform such a job (which we are
used to do for debian package).
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:53 ` Jérôme Marant
@ 2004-09-30 16:06 ` Eli Zaretskii
2004-09-30 17:20 ` Rob Browning
` (2 more replies)
2004-09-30 16:53 ` [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Rob Browning
1 sibling, 3 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 16:06 UTC (permalink / raw)
Cc: rlb, emacs-devel
> Date: Thu, 30 Sep 2004 17:53:39 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: Miles Bader <miles@gnu.org>, rlb@defaultvalue.org,
> emacs-devel@gnu.org
>
> > Like everyone else, I'm grateful for the offer, but I think you know
> > that it takes more to pretest a version than just administrative help
> > we are offered. If this is enough to be able to run 2 pretests in
> > parallel, I just don't know; thus ``I'm not sure'' above.
>
> Why would we necessarily have to go through this pretest phase the
> way it is currently done for major releases?
I don't understand the question; are you saying that bugfix releases
don't need to go through a pretest phase? I wasn't aware something
like that was being proposed in these discussions.
> You look worried about being involved in such releases, but we
> are proposing to be delegated to perform such a job
Unless we will agree to release bugfix versions without pretesting
them, I don't think you will be able to perform that job on your own.
A pretest needs to be done on several platforms, for starters. Also,
at least in the past, some of the changes checked in to the release
branch were non-trivial enough to warrant significant testing.
Changing all that would mean a serious surgery of the current
development procedures. I'm not necessarily opposed to such changes,
but I'd say that a change in version numbering is dwarfed by the
seriousness of issues we need to discuss and agree before such a
surgery could take place.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 16:06 ` Eli Zaretskii
@ 2004-09-30 17:20 ` Rob Browning
2004-09-30 17:58 ` Eli Zaretskii
2004-09-30 17:42 ` Stefan Monnier
2004-09-30 19:09 ` Jérôme Marant
2 siblings, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-09-30 17:20 UTC (permalink / raw)
Cc: jmarant, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
> I don't understand the question; are you saying that bugfix releases
> don't need to go through a pretest phase? I wasn't aware something
> like that was being proposed in these discussions.
I'm not sure about Jerome's position, but as my other message
suggested I'm fairly agnostic with respect to what process the emacs
developers will feel is appropriate for these more minor releases. In
the end, the thing I'll have to evaluate is whether or not I feel I
can handle the work required by that process.
I can understand both the argument that these releases should be
tested just as fully as any other release, and the alternative
argument that they should be treated as much lighter-weight.
The latter argument usually claims that since the changes that go into
these releases are much more controlled (and much smaller) than other
releases, and since it's relatively easy to follow up a problematic
minor release with a repair, then the minor releases won't normally
need as much testing as the more major releases.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 17:20 ` Rob Browning
@ 2004-09-30 17:58 ` Eli Zaretskii
0 siblings, 0 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 17:58 UTC (permalink / raw)
Cc: jmarant, emacs-devel
> Cc: jmarant@free.fr, emacs-devel@gnu.org
> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 30 Sep 2004 12:20:49 -0500
>
> I can understand both the argument that these releases should be
> tested just as fully as any other release, and the alternative
> argument that they should be treated as much lighter-weight.
>
> The latter argument usually claims that since the changes that go into
> these releases are much more controlled (and much smaller) than other
> releases, and since it's relatively easy to follow up a problematic
> minor release with a repair, then the minor releases won't normally
> need as much testing as the more major releases.
I agree that bugfix releases should need less testing, but still we
do have a pretest phase for them.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 16:06 ` Eli Zaretskii
2004-09-30 17:20 ` Rob Browning
@ 2004-09-30 17:42 ` Stefan Monnier
2004-09-30 20:42 ` Jérôme Marant
2004-09-30 19:09 ` Jérôme Marant
2 siblings, 1 reply; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 17:42 UTC (permalink / raw)
Cc: rlb, jmarant, emacs-devel
> I don't understand the question; are you saying that bugfix releases
> don't need to go through a pretest phase? I wasn't aware something
> like that was being proposed in these discussions.
Can we distinguish issues here, lest we end up frustrating people.
I see 3 parts:
1 - "unify" the Debian patches and the RC branch. I.e. that the Debian
maintainer install fixes directly on the RC branch rather than in some
unrelated Debian-only area.
2 - somehow change the bugfix release process (to be more frequent), again
here, basically leveraging from Debian's own bugfix-release process.
3 - fiddle with the release numbering.
As long as 1 and 2 are done in a way that it not Debian-only
(i.e. things like patches that introduce bugs on non-Debian systems),
1 and 2 seem like good ideas to me, basically giving us more manpower
(which is currently only beneficial to Debian).
I think the issue of whether we can do 2 or not is mostly irrelevant: if the
pretests take too much time, then we necessarily won't make them more often.
I.e. if it works it works and if it doesn't, then it works as before.
I don't see what's to discuss.
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 17:42 ` Stefan Monnier
@ 2004-09-30 20:42 ` Jérôme Marant
2004-09-30 21:35 ` Stefan Monnier
2004-09-30 21:36 ` Kim F. Storm
0 siblings, 2 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 20:42 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
Selon Stefan Monnier <monnier@iro.umontreal.ca>:
> I think the issue of whether we can do 2 or not is mostly irrelevant: if the
> pretests take too much time, then we necessarily won't make them more often.
> I.e. if it works it works and if it doesn't, then it works as before.
> I don't see what's to discuss.
But if people think this change in the management of bugfix releases
is a good thing, aren't they going to do everything for it to succeed?
Let's clarify: we do propose to add more manpower for doing the
"dirty job" (honestly, noone loves tracking bugs), but it will never
work without a little cooperation from Emacs developers.
Can I have a guaranty that I'll never be pissed off or ignored on
blocking situations? ("go fuck yourself! You wanted to do the job,
you'll have to do this without us!")
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:42 ` Jérôme Marant
@ 2004-09-30 21:35 ` Stefan Monnier
2004-10-01 7:22 ` Jérôme Marant
2004-10-01 20:22 ` Eli Zaretskii
2004-09-30 21:36 ` Kim F. Storm
1 sibling, 2 replies; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 21:35 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
>> I think the issue of whether we can do 2 or not is mostly irrelevant:
>> if the pretests take too much time, then we necessarily won't make them
>> more often. I.e. if it works it works and if it doesn't, then it works
>> as before. I don't see what's to discuss.
> But if people think this change in the management of bugfix releases
> is a good thing, aren't they going to do everything for it to succeed?
> Let's clarify: we do propose to add more manpower for doing the
> "dirty job" (honestly, noone loves tracking bugs), but it will never
> work without a little cooperation from Emacs developers.
> Can I have a guaranty that I'll never be pissed off or ignored on
> blocking situations? ("go fuck yourself! You wanted to do the job,
> you'll have to do this without us!")
I don't expect any such problem. The worst I expect is that you might
sometimes be prevented from installing a bugfix because it's not "good
enough" (which is something that happens all the time anyway).
Also sometimes things won't go as fast as you'd like.
In order for you not to be frustrated, I think the best option is to take it
slow: after all, the process already exists, and you're just offering to
help out, so you can start by just systematically submitting the patches
that you'd like to apply to Debian's tree (so they get installed in RC),
then regularly bug people to remind them that we should get the next pretest
started, ...
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 21:35 ` Stefan Monnier
@ 2004-10-01 7:22 ` Jérôme Marant
2004-10-01 12:35 ` Stefan
2004-10-03 14:33 ` Richard Stallman
2004-10-01 20:22 ` Eli Zaretskii
1 sibling, 2 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-10-01 7:22 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
Quoting Stefan Monnier <monnier@iro.umontreal.ca>:
> >> I think the issue of whether we can do 2 or not is mostly irrelevant:
> >> if the pretests take too much time, then we necessarily won't make them
> >> more often. I.e. if it works it works and if it doesn't, then it works
> >> as before. I don't see what's to discuss.
>
> > But if people think this change in the management of bugfix releases
> > is a good thing, aren't they going to do everything for it to succeed?
> > Let's clarify: we do propose to add more manpower for doing the
> > "dirty job" (honestly, noone loves tracking bugs), but it will never
> > work without a little cooperation from Emacs developers.
> > Can I have a guaranty that I'll never be pissed off or ignored on
> > blocking situations? ("go fuck yourself! You wanted to do the job,
> > you'll have to do this without us!")
>
> I don't expect any such problem. The worst I expect is that you might
> sometimes be prevented from installing a bugfix because it's not "good
> enough" (which is something that happens all the time anyway).
> Also sometimes things won't go as fast as you'd like.
I've told many time that we won't apply patches without emacs-devel
consents. Usually, by reading the list, you'll notice that we often
forward bug reports and patches to the list. Sometimes we write
patches ourselves for our users.
> In order for you not to be frustrated, I think the best option is to take it
> slow: after all, the process already exists, and you're just offering to
> help out, so you can start by just systematically submitting the patches
> that you'd like to apply to Debian's tree (so they get installed in RC),
> then regularly bug people to remind them that we should get the next pretest
> started, ...
Ok, I see. You are worried about giving CVS access to people with a
too low level of trust.
Well, no matter. The less I do, the more you have to. Maybe will you
manage to prove that it's not worth it because it requires too much
manpower from emacs-devel.
As I said, we are already doing the work of collecting patches (backporting,
and testing) for our users.
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-01 7:22 ` Jérôme Marant
@ 2004-10-01 12:35 ` Stefan
2004-10-01 14:49 ` Jérôme Marant
2004-10-03 14:33 ` Richard Stallman
1 sibling, 1 reply; 109+ messages in thread
From: Stefan @ 2004-10-01 12:35 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
>> I don't expect any such problem. The worst I expect is that you might
>> sometimes be prevented from installing a bugfix because it's not "good
>> enough" (which is something that happens all the time anyway).
>> Also sometimes things won't go as fast as you'd like.
> I've told many time that we won't apply patches without emacs-devel
> consents.
Right. I assumed so.
> Usually, by reading the list, you'll notice that we often forward bug
> reports and patches to the list. Sometimes we write patches ourselves for
> our users.
Yes, I know that, but I have no idea what other patches you apply on the
Debian side. From what I've seen of your reports and patches here, I trust
you can do the job.
>> In order for you not to be frustrated, I think the best option is to take it
>> slow: after all, the process already exists, and you're just offering to
>> help out, so you can start by just systematically submitting the patches
>> that you'd like to apply to Debian's tree (so they get installed in RC),
>> then regularly bug people to remind them that we should get the next pretest
>> started, ...
> Ok, I see. You are worried about giving CVS access to people with a
> too low level of trust.
I didn't say anything about CVS access. I actually assume you'd get CVS
access since I can't see how you could reasonably do the job without
CVS access. Maybe it could be done, strictly speaking, but I can't see how
anyone could accept to do such a job without getting CVS access.
> Well, no matter. The less I do, the more you have to. Maybe will you
> manage to prove that it's not worth it because it requires too much
> manpower from emacs-devel.
I think you misread me. I won't try to slow you down and I hope nobody here
will try to either: I was just recommending to you that you take it slow
for your own sake (so that if we turn out to be unbearable tyrants for you,
you won't feel too bitter).
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-01 12:35 ` Stefan
@ 2004-10-01 14:49 ` Jérôme Marant
2004-10-01 16:25 ` Stefan
0 siblings, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-10-01 14:49 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
Quoting Stefan <monnier@iro.umontreal.ca>:
> > Usually, by reading the list, you'll notice that we often forward bug
> > reports and patches to the list. Sometimes we write patches ourselves for
> > our users.
>
> Yes, I know that, but I have no idea what other patches you apply on the
> Debian side. From what I've seen of your reports and patches here, I trust
> you can do the job.
"We", Rob and I.
> >> In order for you not to be frustrated, I think the best option is to take
> it
> >> slow: after all, the process already exists, and you're just offering to
> >> help out, so you can start by just systematically submitting the patches
> >> that you'd like to apply to Debian's tree (so they get installed in RC),
> >> then regularly bug people to remind them that we should get the next
> pretest
> >> started, ...
>
> > Ok, I see. You are worried about giving CVS access to people with a
> > too low level of trust.
>
> I didn't say anything about CVS access. I actually assume you'd get CVS
> access since I can't see how you could reasonably do the job without
> CVS access. Maybe it could be done, strictly speaking, but I can't see how
> anyone could accept to do such a job without getting CVS access.
>
> > Well, no matter. The less I do, the more you have to. Maybe will you
> > manage to prove that it's not worth it because it requires too much
> > manpower from emacs-devel.
>
> I think you misread me. I won't try to slow you down and I hope nobody here
> will try to either: I was just recommending to you that you take it slow
> for your own sake (so that if we turn out to be unbearable tyrants for you,
> you won't feel too bitter).
Sorry, I probably misread you. It's good to start the discussion early
in order to come to agreements on every single detail, before doing
anything.
Cheers,
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-01 14:49 ` Jérôme Marant
@ 2004-10-01 16:25 ` Stefan
2004-10-01 20:31 ` Jérôme Marant
0 siblings, 1 reply; 109+ messages in thread
From: Stefan @ 2004-10-01 16:25 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
> Sorry, I probably misread you. It's good to start the discussion early
> in order to come to agreements on every single detail, before doing
> anything.
I guess my point was exactly the opposite:
Not only trying to agree on every detail before doing "anything" can
artifically delay the beginning of "anything", but it's simply impossible
because you never know all the possible details beforehand and because
people might originally agree on X but later on discover that it's actually
not acceptable to them in practice, contrary to what they thought.
So in practice, whether you plan it that way or not, you end up fixing
details on the fly. So I think it's better to accept this fact as a given
and work with it rather than against it.
What that boils down to, is that someone's commitment will depend on how
much implicit or explicit positive feedback he experiences *in practice*
(not just in preliminary discussions). So go step by step and "ajuste le
tir" as you move (hpefully) forward.
Theory is just no match to practice,
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-01 16:25 ` Stefan
@ 2004-10-01 20:31 ` Jérôme Marant
2004-10-03 14:33 ` Richard Stallman
0 siblings, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-10-01 20:31 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, emacs-devel
Selon Stefan <monnier@iro.umontreal.ca>:
> I guess my point was exactly the opposite:
> Not only trying to agree on every detail before doing "anything" can
> artifically delay the beginning of "anything", but it's simply impossible
> because you never know all the possible details beforehand and because
> people might originally agree on X but later on discover that it's actually
> not acceptable to them in practice, contrary to what they thought.
>
> So in practice, whether you plan it that way or not, you end up fixing
> details on the fly. So I think it's better to accept this fact as a given
> and work with it rather than against it.
>
> What that boils down to, is that someone's commitment will depend on how
> much implicit or explicit positive feedback he experiences *in practice*
> (not just in preliminary discussions). So go step by step and "ajuste le
> tir" as you move (hpefully) forward.
I'm fine with this. After all, there's nothing to loose and we'll see if
it works in the real. Furthermore, untill 21.4 is release, there's a plenty
of time to think of it.
Cheers,
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-01 7:22 ` Jérôme Marant
2004-10-01 12:35 ` Stefan
@ 2004-10-03 14:33 ` Richard Stallman
1 sibling, 0 replies; 109+ messages in thread
From: Richard Stallman @ 2004-10-03 14:33 UTC (permalink / raw)
Cc: eliz, monnier, rlb, emacs-devel
Ok, I see. You are worried about giving CVS access to people with a
too low level of trust.
I would be glad to give you CVS access for this.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 21:35 ` Stefan Monnier
2004-10-01 7:22 ` Jérôme Marant
@ 2004-10-01 20:22 ` Eli Zaretskii
1 sibling, 0 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-10-01 20:22 UTC (permalink / raw)
Cc: rlb, jmarant, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Sep 2004 17:35:59 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, rlb@defaultvalue.org, emacs-devel@gnu.org
>
> > But if people think this change in the management of bugfix releases
> > is a good thing, aren't they going to do everything for it to succeed?
> > Let's clarify: we do propose to add more manpower for doing the
> > "dirty job" (honestly, noone loves tracking bugs), but it will never
> > work without a little cooperation from Emacs developers.
> > Can I have a guaranty that I'll never be pissed off or ignored on
> > blocking situations? ("go fuck yourself! You wanted to do the job,
> > you'll have to do this without us!")
>
> I don't expect any such problem. The worst I expect is that you might
> sometimes be prevented from installing a bugfix because it's not "good
> enough" (which is something that happens all the time anyway).
> Also sometimes things won't go as fast as you'd like.
>
> In order for you not to be frustrated, I think the best option is to take it
> slow: after all, the process already exists, and you're just offering to
> help out, so you can start by just systematically submitting the patches
> that you'd like to apply to Debian's tree (so they get installed in RC),
> then regularly bug people to remind them that we should get the next pretest
> started, ...
Full agreement.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:42 ` Jérôme Marant
2004-09-30 21:35 ` Stefan Monnier
@ 2004-09-30 21:36 ` Kim F. Storm
1 sibling, 0 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 21:36 UTC (permalink / raw)
Cc: Eli Zaretskii, Stefan Monnier, rlb, emacs-devel
Jérôme Marant <jmarant@free.fr> writes:
> Can I have a guaranty that I'll never be pissed off or ignored on
> blocking situations? ("go fuck yourself! You wanted to do the job,
> you'll have to do this without us!")
I believe all of us will help as much as we can.
But even developers can have a bad day, so no guarantees :-)
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 16:06 ` Eli Zaretskii
2004-09-30 17:20 ` Rob Browning
2004-09-30 17:42 ` Stefan Monnier
@ 2004-09-30 19:09 ` Jérôme Marant
2004-10-01 20:27 ` Eli Zaretskii
2 siblings, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 19:09 UTC (permalink / raw)
Cc: rlb, emacs-devel
Selon Eli Zaretskii <eliz@gnu.org>:
> > Why would we necessarily have to go through this pretest phase the
> > way it is currently done for major releases?
>
> I don't understand the question; are you saying that bugfix releases
> don't need to go through a pretest phase? I wasn't aware something
> like that was being proposed in these discussions.
Me neither. I've never said there wouldn't be any pretest phase.
I'm saying that pretesting a bugfix release is different from
pretesting a major release; it is shorter at least.
I'll also in favour of test cases we can replay every time we
add new patches. Since emacs is able to run in batch, there is
no reason no to do so.
> > You look worried about being involved in such releases, but we
> > are proposing to be delegated to perform such a job
>
> Unless we will agree to release bugfix versions without pretesting
> them, I don't think you will be able to perform that job on your own.
I've never intended to avoid pretesting bugfix releases.
We are doing the same job on the Debian side and we never release
patches in hurry.
> A pretest needs to be done on several platforms, for starters. Also,
> at least in the past, some of the changes checked in to the release
> branch were non-trivial enough to warrant significant testing.
Patches are usually tested in the trunk first at least. We can
delay their application to the bugfix branch while they are being
tested.
> Changing all that would mean a serious surgery of the current
> development procedures. I'm not necessarily opposed to such changes,
> but I'd say that a change in version numbering is dwarfed by the
> seriousness of issues we need to discuss and agree before such a
> surgery could take place.
Isn't what we are doing currently?
--
Jérôme
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 19:09 ` Jérôme Marant
@ 2004-10-01 20:27 ` Eli Zaretskii
2004-10-01 21:47 ` [jerome.marant@free.fr: Re: Possible help with stable Emacsreleases.] Lennart Borgman
0 siblings, 1 reply; 109+ messages in thread
From: Eli Zaretskii @ 2004-10-01 20:27 UTC (permalink / raw)
Cc: rlb, emacs-devel
> Date: Thu, 30 Sep 2004 21:09:04 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: rlb@defaultvalue.org, emacs-devel@gnu.org
>
> I've never said there wouldn't be any pretest phase.
> I'm saying that pretesting a bugfix release is different from
> pretesting a major release; it is shorter at least.
Shorter in practice, yes. But since the process of pretesting is not
a formal one, we don't have any ways to modify that process for bugfix
releases. We simply let pretesters use the release candidate and
report any problems.
> I'll also in favour of test cases we can replay every time we
> add new patches. Since emacs is able to run in batch, there is
> no reason no to do so.
Alas, there's no test suite for Emacs. We discussed this in the past,
so you can find in the archives why it is difficult to come up with
such a test suite (display testing is one problem).
Of course it would be good to have such a suite, but we don't.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacsreleases.]
2004-10-01 20:27 ` Eli Zaretskii
@ 2004-10-01 21:47 ` Lennart Borgman
0 siblings, 0 replies; 109+ messages in thread
From: Lennart Borgman @ 2004-10-01 21:47 UTC (permalink / raw)
Cc: emacs-devel
----- Original Message -----
From: "Eli Zaretskii" <eliz@gnu.org>
: > I'll also in favour of test cases we can replay every time we
: > add new patches. Since emacs is able to run in batch, there is
: > no reason no to do so.
:
: Alas, there's no test suite for Emacs. We discussed this in the past,
: so you can find in the archives why it is difficult to come up with
: such a test suite (display testing is one problem).
Just for the record: There seem to something coming on the GUI side for
testing. The page
http://www.testdriven.com/modules/mylinks/viewcat.php?cid=13 contains two
tools that could be used: Autolt (GPL) and X11::GUITest (GPL). As far as I
can see Autolt is only for Windows platforms and X11::GUITest is in an early
beta stage.
I guess testing on MS Windows has some drawbacks. However it could also be a
good idea since many things are made available on the screen. (This has been
part of MS investment in accessability.) I don't have any idea how the state
of these things are on X, but I guess there is something similar since
X11::GUITest is beeing written. Anyway tests could be written in layers to
hide the dependency of the exact tool used. (But this would perhaps make it
slow, beeing quite contrary to the idea of unit tests.)
- Lennart
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:53 ` Jérôme Marant
2004-09-30 16:06 ` Eli Zaretskii
@ 2004-09-30 16:53 ` Rob Browning
1 sibling, 0 replies; 109+ messages in thread
From: Rob Browning @ 2004-09-30 16:53 UTC (permalink / raw)
Cc: Eli Zaretskii, emacs-devel, Miles Bader
Jérôme Marant <jmarant@free.fr> writes:
> Why would we necessarily have to go through this pretest phase the
> way it is currently done for major releases?
I don't think it's reasonable to presume that emacs-devel would want
to be as agressive about these micro releases as Debian. Debian's
model is different, handling the testing *after* the intial release
via the progression from unstable -> testing -> stable.
During this entire process (of considering helping make emacs stable
releases), I've felt like this issue is likely to be the critical one.
It's possible that the emacs developers will want to be cautious
enough about all the releases (even the minor ones) that the overhead
will be too high for two people (who are already busy) to handle on
their own. That's fine, and I can understand it.
The key here, in my opinion, is to find out what the emacs developers
*would* be comfortable with, then figure out how that would fit in
with the work we already have to do in Debian, and then determine
whether or not the impedence mismatch is low enough that it's an
overall win for everyone.
If not, then we should just go back to working on the Debian packages.
In that situation, I suppose we could also consider offering an
unofficial "branch" that just contained the non-debian-specific
patches from debian/patches/*, but I wouldn't be excited about that
unless most of the emacs developers are comfortable with it.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:37 ` Eli Zaretskii
2004-09-30 15:53 ` Jérôme Marant
@ 2004-09-30 19:15 ` Robert J. Chassell
2004-09-30 20:26 ` Jérôme Marant
2004-10-04 22:40 ` Rob Browning
1 sibling, 2 replies; 109+ messages in thread
From: Robert J. Chassell @ 2004-09-30 19:15 UTC (permalink / raw)
As I understand, we are talking about two different entities:
* Debian, who only work with releases from the Emacs developers
* Emacs, the developers, who work with CVS
The Debian people have been making Debian packages out of Emacs for
years. They are not planning on becoming Emacs developers.
They have not and are *not* proposing to test a release from _Emacs_
developers.
The Debian people are proposing
1. to continue to make Debian packages out of Emacs releases, and,
2. occasionally to fix bugs in their packages, which means making new
Debian packages.
They hope to get their bug fixes from the Emacs CVS development trunk,
but they are not, themselves proposing to do any of the pretesting
needed for a release from _Emacs_ developers.
In other words, the Debian people are *not* proposing to do a
`pretest' as Emacs developers understand it. They are proposing to
back port some bug fixes to an old version previously released by
Emacs developers.
Currently, the Debian Emacs has a version number that looks like this:
21.3+1
(I just checked using `apt-cache show emacs21'; the full Debian Emacs
version number is `21.3+1-7' but my understanding is that the `7'
merely means this is the 7th Debian package of this series and is as
irrelevant to us as the fourth component of my emacs-version is to
you.)
Should the Debian version number remain like that or should it be
changed? For example, it might be changed to:
21.3.1
and be distinguished from the version number of the current CVS, which
looks like this:
21.3.50
The advantage of a closer connection with the Debian people is that we
can be more confident in our pretests that some of the bug fixes will
work (probabilistically speaking). This is because the Debian people
will have backported them and tested them on a previous release.
(This does not mean that the changes will be without bugs in the new
release; it means that they worked for the previous release.
Pretesting will still be necessary. But, probabilistically speaking,
we can be somewhat more confident.)
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 19:15 ` Robert J. Chassell
@ 2004-09-30 20:26 ` Jérôme Marant
2004-10-03 14:20 ` Robert J. Chassell
2004-10-04 22:40 ` Rob Browning
1 sibling, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 20:26 UTC (permalink / raw)
Cc: emacs-devel
Selon "Robert J. Chassell" <bob@rattlesnake.com>:
> As I understand, we are talking about two different entities:
>
> * Debian, who only work with releases from the Emacs developers
>
> * Emacs, the developers, who work with CVS
>
> The Debian people have been making Debian packages out of Emacs for
> years. They are not planning on becoming Emacs developers.
>
> They have not and are *not* proposing to test a release from _Emacs_
> developers.
>
> The Debian people are proposing
>
> 1. to continue to make Debian packages out of Emacs releases, and,
>
> 2. occasionally to fix bugs in their packages, which means making new
> Debian packages.
Robert,
Please re-read the whole thread and come back when you have done so.
You misunderstood everything, no offence meant.
Thanks in advance.
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 20:26 ` Jérôme Marant
@ 2004-10-03 14:20 ` Robert J. Chassell
0 siblings, 0 replies; 109+ messages in thread
From: Robert J. Chassell @ 2004-10-03 14:20 UTC (permalink / raw)
Jérôme Marant wrote,
Please re-read the whole thread and come back when you have done so.
You misunderstood everything, no offence meant.
I just re-read the whole thread and as far as I can see, I described
the situation correctly.
What is not clear to me is whether Marant considers releases such as
21.2 and 21.3 as `stable'. If not, then I did not describe his
proposal correctly.
My understanding is that currently, *every* release by the Emacs
developers is intended to be `stable'. Every release is one that
should be able to fit into the Debian stable distribution without
first going through unstable and testing. 21.2 was supposed to have
been a tested and stable release.
This is a totally different release model than that used in Debian.
As Rob Browning said
Debian's model is different, handling the testing *after* the
intial release via the progression from unstable -> testing ->
stable.
Rob also introduced the term `micro release'.
In this language, Emacs major and minor releases are intended to go
into Debian stable immediately; `micro releases' are intended to go
into Debian unstable.
With Rob's term, then Marant's original proposal makes sense as one
favoring `micro releases':
http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00935.html
What we propose is to maintain bugfix releases from stable
releases. This is exactly the kind of job we are doing with
the Debian Emacs package: collecting bugfixes, backporting
fixes from the trunk.
in which the proposal is to make releases that fix bugs in Emacs
releases such as 21.2 and 21.3.
However, if you do not think of 21.2 and 21.3 as stable, it also makes
sense as a proposal to stop Emacs developers from making releases like
21.2 and 21.3.
Put another way, two courses are possible:
* to make `micro' releases from stable and pretested releases such
as 21.2 and 21.3;
* to abolish `major bug fix' releases such as 21.2 and 21.3 and make
all bug fix releases off of a release such as 21.1.
I realize I have been presuming that Emacs developers would continue
to make bug fix releases as well as new feature releases and that they
would also stick to their model of pretesting all releases so they are
as good and as stable as they can make them.
Jérôme's proposal made sense with this presumption.
But it also made sense if he proposed abolishing pretested bug fix
releases by the Emacs developers and replacing them with unstable and
less tested releases that then go through post-release testing.
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 19:15 ` Robert J. Chassell
2004-09-30 20:26 ` Jérôme Marant
@ 2004-10-04 22:40 ` Rob Browning
2004-10-06 5:28 ` Richard Stallman
2004-10-06 9:12 ` Eli Zaretskii
1 sibling, 2 replies; 109+ messages in thread
From: Rob Browning @ 2004-10-04 22:40 UTC (permalink / raw)
Cc: emacs-devel
"Robert J. Chassell" <bob@rattlesnake.com> writes:
> The Debian people are proposing
>
> 1. to continue to make Debian packages out of Emacs releases, and,
>
> 2. occasionally to fix bugs in their packages, which means making new
> Debian packages.
Actually, the overall goal here was to figure out some way that the
work that we do on the Debian side can benefit a wider audience.
We might well release 10 Debian revisions in a given year, and each
one may fix some number of bugs in the current "stable" upstream Emacs
distribution. We fix some of these bugs with backports from Emacs
CVS, some with patches from users, and some by our own hacking.
So we wanted to see if together with emacs-devel, we could come up
with a way to make those releases more publically available, so that
others can benefit from the improvements on a shorter timescale than
that of traditional emacs releases.
One way to do that might be for Emacs CVS to have a "branch" (or
whatever) that only allowed *really* uncontroversial bugfixes, and
hence was supposed to be nearly ready for release all the time. In
that scenario, Jerome and I could commit our patches there and then
make relatively more frequent releases. Since the changes are
required to be "minor", if one of these releases breaks something, we
should be able to just back out the change and release a new version
immediately. Whether these releases would be called X.Y.Z, or
W.X.Y.Z, X.Y.bugfix.N, or something else doesn't really matter (though
see my next post about major number choices).
Another alternative might be for us to just maintain unofficial Debian
sub-releases. We could provide emacs-debian...tar.gz on
people.debian.org, and make it clear that the release is unofficial,
but contains all of the non-Debian-specific fixes from the Debian
package.
Of course, I'm sure there are other solutions I'm not thinking of at
the moment.
> Currently, the Debian Emacs has a version number that looks like this:
>
> 21.3+1
The reason we have 21.3+1 rather than just 21.3 is that we repackage
the upstream source. In particular our orig.tar.gz file contains leim
and does not contain any .elc files. We use +1 to make it clearer
that this isn't exactly an upstream version, while still allowing dpkg
to sort the versions correctly.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-04 22:40 ` Rob Browning
@ 2004-10-06 5:28 ` Richard Stallman
2004-10-06 9:12 ` Eli Zaretskii
1 sibling, 0 replies; 109+ messages in thread
From: Richard Stallman @ 2004-10-06 5:28 UTC (permalink / raw)
Cc: bob, emacs-devel
One way to do that might be for Emacs CVS to have a "branch" (or
whatever) that only allowed *really* uncontroversial bugfixes, and
hence was supposed to be nearly ready for release all the time. In
that scenario, Jerome and I could commit our patches there and then
make relatively more frequent releases. Since the changes are
required to be "minor", if one of these releases breaks something, we
should be able to just back out the change and release a new version
immediately.
This is more or less the way we handled 21.2 and 21.3.
I think it is an uncontroversial proposal.
I gladly accept your offer to do this.
Whether these releases would be called X.Y.Z, or
W.X.Y.Z, X.Y.bugfix.N, or something else doesn't really matter (though
see my next post about major number choices).
I think the question of version numbering is the ony one we are in
doubt about. We would like you to do this maintenance.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-04 22:40 ` Rob Browning
2004-10-06 5:28 ` Richard Stallman
@ 2004-10-06 9:12 ` Eli Zaretskii
1 sibling, 0 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-10-06 9:12 UTC (permalink / raw)
Cc: bob, emacs-devel
> From: Rob Browning <rlb@defaultvalue.org>
> Date: Mon, 04 Oct 2004 17:40:36 -0500
> Cc: emacs-devel@gnu.org
>
> So we wanted to see if together with emacs-devel, we could come up
> with a way to make those releases more publically available, so that
> others can benefit from the improvements on a shorter timescale than
> that of traditional emacs releases.
>
> One way to do that might be for Emacs CVS to have a "branch" (or
> whatever) that only allowed *really* uncontroversial bugfixes, and
> hence was supposed to be nearly ready for release all the time.
That's how Emacs is being maintained since v21.1: there's a bug-fix
branch where only safe changes are being made. The last version
released from that branch is 21.3.
How frequent can releases be made from that branch is another
question, and the answer depends mostly on how the pretest phase is
handled.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:21 ` Eli Zaretskii
2004-09-30 14:32 ` Jérôme Marant
2004-09-30 14:34 ` Miles Bader
@ 2004-09-30 14:55 ` Kim F. Storm
2004-09-30 15:41 ` Eli Zaretskii
2004-09-30 15:15 ` Rob Browning
3 siblings, 1 reply; 109+ messages in thread
From: Kim F. Storm @ 2004-09-30 14:55 UTC (permalink / raw)
Cc: jmarant, Rob Browning, emacs-devel
"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.
And manually going through all the lisp modules changing "X.N" to "X.(N+1)".
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:55 ` Kim F. Storm
@ 2004-09-30 15:41 ` Eli Zaretskii
0 siblings, 0 replies; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 15:41 UTC (permalink / raw)
Cc: rlb, jmarant, emacs-devel
> From: storm@cua.dk (Kim F. Storm)
> Date: Thu, 30 Sep 2004 16:55:02 +0200
> Cc: jmarant@free.fr, Rob Browning <rlb@defaultvalue.org>, emacs-devel@gnu.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.
>
> And manually going through all the lisp modules changing "X.N" to "X.(N+1)".
That can be handled by using a far-ahead value for the minor version
on the trunk (we did that in the past).
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 14:21 ` Eli Zaretskii
` (2 preceding siblings ...)
2004-09-30 14:55 ` Kim F. Storm
@ 2004-09-30 15:15 ` Rob Browning
2004-09-30 15:48 ` Eli Zaretskii
` (2 more replies)
3 siblings, 3 replies; 109+ messages in thread
From: Rob Browning @ 2004-09-30 15:15 UTC (permalink / raw)
Cc: jmarant, emacs-devel
"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
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:15 ` Rob Browning
@ 2004-09-30 15:48 ` Eli Zaretskii
2004-09-30 15:58 ` Jérôme Marant
2004-09-30 17:31 ` Stefan Monnier
2004-10-02 20:47 ` Kai Grossjohann
2 siblings, 1 reply; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 15:48 UTC (permalink / raw)
Cc: jmarant, emacs-devel
> Cc: emacs-devel@gnu.org, jmarant@free.fr
> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 30 Sep 2004 10:15:06 -0500
>
> So the presumption was that there won't be more than about 50 bugfixes
> before the next "primary release".
Yes.
In my experience, most pretest versions started from .80, with some
major ones beginning at .70.
> 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?
I don't think it matters: in any case, it takes a non-trivial amount
of time to run a pretest.
One related problem is that AFAIK we have no clear criteria for when a
version, be it bugfix or major, is ready for a release.
> (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.)
I think Emacs is such a large package that it doesn't make sense to
have a new version more than once in a month or two. But that, too,
was never discussed nor codified since we never could end a pretest as
soon as that. Perhaps we should delay this discussion until we get to
such a situation for the first time.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:48 ` Eli Zaretskii
@ 2004-09-30 15:58 ` Jérôme Marant
0 siblings, 0 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-09-30 15:58 UTC (permalink / raw)
Cc: Rob Browning, emacs-devel
Quoting Eli Zaretskii <eliz@gnu.org>:
> I think Emacs is such a large package that it doesn't make sense to
> have a new version more than once in a month or two. But that, too,
> was never discussed nor codified since we never could end a pretest as
> soon as that. Perhaps we should delay this discussion until we get to
> such a situation for the first time.
How about using odd minor version numbers for development versions
and even minor version number for stable releases?
Hence, 21.4.z would be a stable release and we would freely use z.
21.5.z would be the next development release renamed 22.0 later?
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:15 ` Rob Browning
2004-09-30 15:48 ` Eli Zaretskii
@ 2004-09-30 17:31 ` Stefan Monnier
2004-09-30 18:00 ` Eli Zaretskii
2004-10-02 20:47 ` Kai Grossjohann
2 siblings, 1 reply; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 17:31 UTC (permalink / raw)
Cc: Eli Zaretskii, jmarant, emacs-devel
>> 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".
No, the .50 is used for all the "versions" until the first pretest.
The pretests then start at .90, then .91, .92, ... and can go to
.9999999999999999997, ... so we have a large enough pool of pretest
version numbers.
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 17:31 ` Stefan Monnier
@ 2004-09-30 18:00 ` Eli Zaretskii
2004-09-30 18:33 ` Stefan Monnier
0 siblings, 1 reply; 109+ messages in thread
From: Eli Zaretskii @ 2004-09-30 18:00 UTC (permalink / raw)
Cc: jmarant, rlb, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Sep 2004 13:31:03 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, jmarant@free.fr, emacs-devel@gnu.org
>
> No, the .50 is used for all the "versions" until the first pretest.
> The pretests then start at .90, then .91, .92, ... and can go to
> .9999999999999999997, ... so we have a large enough pool of pretest
> version numbers.
Actually, some major releases went above .100 in the minor-minor
field.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 18:00 ` Eli Zaretskii
@ 2004-09-30 18:33 ` Stefan Monnier
2004-09-30 21:39 ` Andreas Schwab
0 siblings, 1 reply; 109+ messages in thread
From: Stefan Monnier @ 2004-09-30 18:33 UTC (permalink / raw)
Cc: jmarant, rlb, emacs-devel
>> No, the .50 is used for all the "versions" until the first pretest.
>> The pretests then start at .90, then .91, .92, ... and can go to
>> .9999999999999999997, ... so we have a large enough pool of pretest
>> version numbers.
> Actually, some major releases went above .100 in the minor-minor
> field.
True, that's another way to continue the sequence after .90, ..., .99
and IIRC both have been used in the past. I like the .999 scheme better,
tho ;-)
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 18:33 ` Stefan Monnier
@ 2004-09-30 21:39 ` Andreas Schwab
0 siblings, 0 replies; 109+ messages in thread
From: Andreas Schwab @ 2004-09-30 21:39 UTC (permalink / raw)
Cc: Eli Zaretskii, rlb, jmarant, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> True, that's another way to continue the sequence after .90, ..., .99
> and IIRC both have been used in the past. I like the .999 scheme better,
> tho ;-)
Since version numbers are not fractions, but rather sequences of numbers,
continuing with .100 is more natural.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-30 15:15 ` Rob Browning
2004-09-30 15:48 ` Eli Zaretskii
2004-09-30 17:31 ` Stefan Monnier
@ 2004-10-02 20:47 ` Kai Grossjohann
2 siblings, 0 replies; 109+ messages in thread
From: Kai Grossjohann @ 2004-10-02 20:47 UTC (permalink / raw)
Rob Browning <rlb@defaultvalue.org> writes:
> "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".
No: 21.3.1 means the first compilation of 21.3, 21.3.2 means the
second compilation of 21.3, and so on. That is, the last number
allows you to see how often the person has invoked "make" from the
same source tree.
21.3.50.1 is the first "make" from the current CVS head.
So if somebody compiles the same source tree 50 times, then we might
get a confusion, because the difference between 21.3.50 (50th build of
current stable release) and 21.3.50.1 (first build of CVS head) is
just too small, and people will routinely use 21.3.50 to refer to CVS
head.
A bugfix of 21.3 will result in 21.4, and the CVS head will be
renumbered to 21.4.50.
I do not know of any other project using a similar versioning scheme.
Kai
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 19:29 ` Rob Browning
` (3 preceding siblings ...)
2004-09-30 14:21 ` Eli Zaretskii
@ 2004-09-30 15:59 ` Richard Stallman
2004-10-01 6:24 ` Francesco Potorti`
5 siblings, 0 replies; 109+ messages in thread
From: Richard Stallman @ 2004-09-30 15:59 UTC (permalink / raw)
Cc: storm, emacs-devel, monnier, jmarant, miles
Imagine that 21.4 has been relased, and then imagine Jerome and I have
made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
that were submitted to Debian, that have been approved by the Emacs
developers. Now imagine that you're preparing to make a new release
from the "main" upstream development branch. What do you call it?
22.1, I think.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-09-29 19:29 ` Rob Browning
` (4 preceding siblings ...)
2004-09-30 15:59 ` Richard Stallman
@ 2004-10-01 6:24 ` Francesco Potorti`
2004-10-04 22:58 ` Rob Browning
5 siblings, 1 reply; 109+ messages in thread
From: Francesco Potorti` @ 2004-10-01 6:24 UTC (permalink / raw)
Cc: rms, Jerome Marant, emacs-devel, Stefan Monnier, Kim F. Storm,
Miles Bader
>Imagine that 21.4 has been relased, and then imagine Jerome and I have
>made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
>that were submitted to Debian, that have been approved by the Emacs
>developers. Now imagine that you're preparing to make a new release
>from the "main" upstream development branch. What do you call it? If
>you pick 21.8 and then you're unexpectedly delayed for a month or two
>(for whatever reason), then we're in trouble if we need to make a
>bugfix release (imagine a data-destroying bug of some kind that can't
>wait). We'd need something between 21.7 and 21.8.
Fortunately this problem does not exist. The release number is
generated the moment that the tarball is made, so no provision or number
locking is needed in advance of the very last step of making the
tarball.
>Of course if you don't the possibility that you might have to keep
>changing the pending upstream release number whenever we make a minor
>bigfix release, then there's no problem, but even so, I suspect
>there's also some value in people being able to easily tell the
>difference between a truly minor bugfix release and one that's been
>worked on for (historically) on the order of a year.
While I want to make clear once again that this is a separate issue,
which is completely independent from the previous one, yes, I agree that
clearly indicating which releases are bugfix-only and which are not
would be valuable.
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-01 6:24 ` Francesco Potorti`
@ 2004-10-04 22:58 ` Rob Browning
2004-10-05 8:34 ` Kim F. Storm
2004-10-05 11:26 ` Stefan
0 siblings, 2 replies; 109+ messages in thread
From: Rob Browning @ 2004-10-04 22:58 UTC (permalink / raw)
Cc: rms, Jerome Marant, emacs-devel, Stefan Monnier, Kim F. Storm,
Miles Bader
Francesco Potorti` <pot@gnu.org> writes:
> While I want to make clear once again that this is a separate issue,
> which is completely independent from the previous one, yes, I agree
> that clearly indicating which releases are bugfix-only and which are
> not would be valuable.
Actually now that I think about it, at least for those packaging
Emacs, it's somewhat critical. Right now Debian pacakges Emacs as
emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
This is done under the assumption that only a change in XY signals the
potential for major breakage.
The Debian Emacs Policy is set up based on that assumption so that we
can have multiple major versions of Emacs installed without breakage.
This was very important back during the transition from emacs19 to
emacs20 because there were many users who had code that they couldn't
afford to port immediately. It can also be important because it may
take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
psgml, ...) to be updated to work with the new major version of Emacs.
(In part, the Debian policy arranges things so that a given add-on
package can tell which Emacs "flavor" it's being installed for, and
can make decisions based on that if necessary.)
If Emacs ever had a nominal minor release that was really a major
release (which was significantly incompatible in some way), it could
cause a painful transition.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-04 22:58 ` Rob Browning
@ 2004-10-05 8:34 ` Kim F. Storm
2004-10-05 15:01 ` Rob Browning
2004-10-05 11:26 ` Stefan
1 sibling, 1 reply; 109+ messages in thread
From: Kim F. Storm @ 2004-10-05 8:34 UTC (permalink / raw)
Cc: Francesco Potorti`, Jerome Marant, emacs-devel
Rob Browning <rlb@defaultvalue.org> writes:
> Francesco Potorti` <pot@gnu.org> writes:
>
>> While I want to make clear once again that this is a separate issue,
>> which is completely independent from the previous one, yes, I agree
>> that clearly indicating which releases are bugfix-only and which are
>> not would be valuable.
>
> Actually now that I think about it, at least for those packaging
> Emacs, it's somewhat critical. Right now Debian pacakges Emacs as
> emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> This is done under the assumption that only a change in XY signals the
> potential for major breakage.
>
> The Debian Emacs Policy is set up based on that assumption so that we
> can have multiple major versions of Emacs installed without breakage.
> This was very important back during the transition from emacs19 to
> emacs20 because there were many users who had code that they couldn't
> afford to port immediately. It can also be important because it may
> take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
> psgml, ...) to be updated to work with the new major version of Emacs.
IIRC, 20.6 -> 20.7 was a pretty major update.
>
> (In part, the Debian policy arranges things so that a given add-on
> package can tell which Emacs "flavor" it's being installed for, and
> can make decisions based on that if necessary.)
>
> If Emacs ever had a nominal minor release that was really a major
> release (which was significantly incompatible in some way), it could
> cause a painful transition.
I know for sure that there are things in CVS emacs that breaks code
which run ok on 21.3. Specifically this change has caused problems:
** `split-string' now includes null substrings in the returned list if
the optional argument SEPARATORS is non-nil and there are matches for
SEPARATORS at the beginning or end of the string. If SEPARATORS is
nil, or if the new optional third argument OMIT-NULLS is non-nil, all
empty matches are omitted from the returned list.
This could be another argument for using 22.1 for the next release.
Another example is the version of cua-mode that I distribute from my
own web-site. It works fine with 21.3, but it does not run on CVS
emacs due to changes in key parsing.
Instead a cua-mode specifically developed for CVS emacs is included
with CVS emacs, and the user _must_ remove the old cua-mode
installation from the load path before using the one included with CVS
emacs.
I suppose there may be other cases like that, as CVS emacs include
quite a number of new packages.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 8:34 ` Kim F. Storm
@ 2004-10-05 15:01 ` Rob Browning
2004-10-05 16:18 ` Juri Linkov
0 siblings, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-10-05 15:01 UTC (permalink / raw)
Cc: Francesco Potorti`, Jerome Marant, emacs-devel
storm@cua.dk (Kim F. Storm) writes:
>> emacs20 because there were many users who had code that they couldn't
>> afford to port immediately. It can also be important because it may
>> take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
>> psgml, ...) to be updated to work with the new major version of Emacs.
>
> IIRC, 20.6 -> 20.7 was a pretty major update.
Well from what I recall, it wasn't nearly the same as say the Emacs 19
to Emacs 20 transition, at least from the Debian perspective. I don't
recall any serious problems, though that doesn't mean that I haven't
just forgotten them.
> This could be another argument for using 22.1 for the next release.
Hmm. I thought I saw some other posts that suggested that you were
going to number the next release 22.1. If not, and if there really is
the potential for significant breakage, then please reconsider. If
there may be trouble, what would be the argument against naming it
22.1?
> I suppose there may be other cases like that, as CVS emacs include
> quite a number of new packages.
Changes like that may be less problematic for Debian. For some subset
of problems of that nature, we can solve them using packaging
dependencies, i.e. (i.e. Conflicts: calc << X.Y.Z or whatever's
needed). We can work that kind of thing out in unstable.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 15:01 ` Rob Browning
@ 2004-10-05 16:18 ` Juri Linkov
2004-10-05 16:34 ` Rob Browning
2004-10-05 17:03 ` Stefan Monnier
0 siblings, 2 replies; 109+ messages in thread
From: Juri Linkov @ 2004-10-05 16:18 UTC (permalink / raw)
Cc: pot, emacs-devel, jmarant, storm
Rob Browning <rlb@defaultvalue.org> writes:
> storm@cua.dk (Kim F. Storm) writes:
>> This could be another argument for using 22.1 for the next release.
>
> Hmm. I thought I saw some other posts that suggested that you were
> going to number the next release 22.1. If not, and if there really is
> the potential for significant breakage, then please reconsider. If
> there may be trouble, what would be the argument against naming it
> 22.1?
Everyone already refers to Emacs 22 as Unicode version of Emacs.
Releasing 21.4 as 22.1 will cause a lot of confusion: people will
start downloading Emacs 22.1 as "Unicode Emacs" and later discover
it's actually not what they thought.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 16:18 ` Juri Linkov
@ 2004-10-05 16:34 ` Rob Browning
2004-10-05 17:03 ` Stefan Monnier
1 sibling, 0 replies; 109+ messages in thread
From: Rob Browning @ 2004-10-05 16:34 UTC (permalink / raw)
Cc: pot, emacs-devel, jmarant, storm
Juri Linkov <juri@jurta.org> writes:
> Everyone already refers to Emacs 22 as Unicode version of Emacs.
> Releasing 21.4 as 22.1 will cause a lot of confusion: people will
> start downloading Emacs 22.1 as "Unicode Emacs" and later discover
> it's actually not what they thought.
Presuming the developers wanted to make the change, I wonder if just
posting an explanation on emacs-devel and a few other suitable places
would clear things up.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 16:18 ` Juri Linkov
2004-10-05 16:34 ` Rob Browning
@ 2004-10-05 17:03 ` Stefan Monnier
2004-10-06 8:39 ` Kim F. Storm
1 sibling, 1 reply; 109+ messages in thread
From: Stefan Monnier @ 2004-10-05 17:03 UTC (permalink / raw)
Cc: pot, storm, jmarant, Rob Browning, emacs-devel
> Everyone already refers to Emacs 22 as Unicode version of Emacs.
That's a gross overstatement.
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 17:03 ` Stefan Monnier
@ 2004-10-06 8:39 ` Kim F. Storm
0 siblings, 0 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-10-06 8:39 UTC (permalink / raw)
Cc: Juri Linkov, pot, jmarant, Rob Browning, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Everyone already refers to Emacs 22 as Unicode version of Emacs.
>
> That's a gross overstatement.
That's a gross understatement :-)
I think more people have been confused by 21.3, 21.3.50, and 21.4 than
you can find people who have ever heard about "unicode emacs".
(but I don't want to take a poll :-)
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-04 22:58 ` Rob Browning
2004-10-05 8:34 ` Kim F. Storm
@ 2004-10-05 11:26 ` Stefan
2004-10-05 11:40 ` Jérôme Marant
2004-10-05 14:39 ` Rob Browning
1 sibling, 2 replies; 109+ messages in thread
From: Stefan @ 2004-10-05 11:26 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, Jerome Marant, emacs-devel, Kim F. Storm,
Miles Bader
> Actually now that I think about it, at least for those packaging
> Emacs, it's somewhat critical. Right now Debian pacakges Emacs as
> emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> This is done under the assumption that only a change in XY signals the
> potential for major breakage.
While I mostly agree that we should change emacs-major-version for
non-bug-fix releases, I think that limitations of specific packaging systems
are not a motivating factor.
I actually think that your problems should cause you to reconsider the
design of the packaging system since such problems surely happen with other
packages as well.
Stefan "who's generally disappointed by the poor support for
multiple concurrently installed versions of a single package
in most package systems"
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 11:26 ` Stefan
@ 2004-10-05 11:40 ` Jérôme Marant
2004-10-06 11:09 ` Nick Roberts
2004-10-05 14:39 ` Rob Browning
1 sibling, 1 reply; 109+ messages in thread
From: Jérôme Marant @ 2004-10-05 11:40 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, emacs-devel, Kim F. Storm, Rob Browning,
Miles Bader
Quoting Stefan <monnier@iro.umontreal.ca>:
> > Actually now that I think about it, at least for those packaging
> > Emacs, it's somewhat critical. Right now Debian pacakges Emacs as
> > emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> > This is done under the assumption that only a change in XY signals the
> > potential for major breakage.
>
> While I mostly agree that we should change emacs-major-version for
> non-bug-fix releases, I think that limitations of specific packaging systems
> are not a motivating factor.
>
> I actually think that your problems should cause you to reconsider the
> design of the packaging system since such problems surely happen with other
> packages as well.
Versioning package names is so far the best solution for avoiding binary
incompatibilities after upgrades.
It is usually being done with shared library package names by appending
the soname to the library name.
If 21.4 brings incompatibilities (that is, emacs modes needs to be modified
in order to work properly), we may decide to change the package name
to emacs21.4.
Cheers,
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 11:40 ` Jérôme Marant
@ 2004-10-06 11:09 ` Nick Roberts
2004-10-06 11:46 ` Jérôme Marant
0 siblings, 1 reply; 109+ messages in thread
From: Nick Roberts @ 2004-10-06 11:09 UTC (permalink / raw)
Cc: emacs-devel
This thread has discussed help with stable Emacs releases. Much of the
frustration on this list seems to occur earlier in the development
process. Other projects, notably XEmacs, make beta releases for inclusion with
unstable GNU/Linux distributions such as Debian's sid and the Mandrake
Cooker. It occurs to me that if Emacs did this too i.e made beta releases from
the trunk, there would be more pairs of eyes and it would therefore make for a
faster stable release. It doesn't seem realistic or even reasonable to expect
a handful of developers to do all the work. I don't know, maybe the pretests
do get included in such distributions but it seems to me that more leverage
could be obtained by always having a beta version (not in CVS) available.
Nick
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-06 11:09 ` Nick Roberts
@ 2004-10-06 11:46 ` Jérôme Marant
0 siblings, 0 replies; 109+ messages in thread
From: Jérôme Marant @ 2004-10-06 11:46 UTC (permalink / raw)
Cc: emacs-devel
Quoting Nick Roberts <nickrob@snap.net.nz>:
>
> This thread has discussed help with stable Emacs releases. Much of the
> frustration on this list seems to occur earlier in the development
> process. Other projects, notably XEmacs, make beta releases for inclusion
> with
> unstable GNU/Linux distributions such as Debian's sid and the Mandrake
> Cooker. It occurs to me that if Emacs did this too i.e made beta releases
> from
> the trunk, there would be more pairs of eyes and it would therefore make for
> a
> faster stable release. It doesn't seem realistic or even reasonable to expect
> a handful of developers to do all the work. I don't know, maybe the pretests
> do get included in such distributions but it seems to me that more leverage
> could be obtained by always having a beta version (not in CVS) available.
As far as I know, XEmacs people do both stable (say bugfix) releases
and beta releases.
--
Jérôme Marant
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 11:26 ` Stefan
2004-10-05 11:40 ` Jérôme Marant
@ 2004-10-05 14:39 ` Rob Browning
2004-10-05 14:53 ` Stefan Monnier
1 sibling, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-10-05 14:39 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, Jerome Marant, emacs-devel, Kim F. Storm,
Miles Bader
Stefan <monnier@iro.umontreal.ca> writes:
> While I mostly agree that we should change emacs-major-version for
> non-bug-fix releases, I think that limitations of specific packaging
> systems are not a motivating factor.
Perhaps not for you, though upstream can be a *great* help when their
versioning behaves sanely.
> I actually think that your problems should cause you to reconsider
> the design of the packaging system since such problems surely happen
> with other packages as well.
I'm not sure what kind of improvements you're suggesting, and for
which kinds of problems, but I don't recall a situation where we
*can't* accomodate multiple installs of something in Debian. It's
just a matter of how much hassle it is and how far we have to diverge
from the upstream code, and that's usually determined by how much
attention the upstream developers have paid to the issue. (It's also,
depending on the package, a question of manpower.)
For example, if emacs started making releases with major breakage that
only bumped the third version number, i.e. 21.4.1, then (as Jerome
suggests) we'd just have to start releasing emacs packages which
include all three versions: emacs21.4.1.
All that said, by all means, if you can suggest improvements, please
do.
> Stefan "who's generally disappointed by the poor support for
> multiple concurrently installed versions of a single package
> in most package systems"
This blame (though not generally in the case of emacs) may lay as much
at the feet of the upstream developers as the downstream packagers
(speaking as one who works on both sides). If the upstream hasn't
ever considered the problem, then it can be very difficult, and
require substantial hacking, to alter the upstream to handle multiple
installed versions. This can be further hindered by the available OS
and tools. For example, the fact that dlopen doesn't support
versioning the way that ld.so does can make it difficult to allow
multiply installed versions of software that relies on dlopened
libraries, unless the upstream has considered that problem and chosen
suitably unique library *names* for those libraries.
The more classic example is an upstream that doesn't bump its library
soname versions when making backward incompatible changes to the
code. This can be a big problem.
All of these examples assume that the distribution is going to try to
conform to the FHS. If you're willing to ignore that, then you may
have other options.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 14:39 ` Rob Browning
@ 2004-10-05 14:53 ` Stefan Monnier
2004-10-05 15:28 ` Rob Browning
0 siblings, 1 reply; 109+ messages in thread
From: Stefan Monnier @ 2004-10-05 14:53 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, Jerome Marant, emacs-devel, Kim F. Storm,
Miles Bader
> I'm not sure what kind of improvements you're suggesting, and for
> which kinds of problems, but I don't recall a situation where we
> *can't* accomodate multiple installs of something in Debian. It's
> just a matter of how much hassle it is and how far we have to diverge
> from the upstream code, and that's usually determined by how much
> attention the upstream developers have paid to the issue. (It's also,
> depending on the package, a question of manpower.)
Just as it is possible if you don't use packages, it should be possible for
the end user to decide that she wants to install Emacs versions 20.3, 20.4,
21.1, 21.2, and 21.3.
> This blame (though not generally in the case of emacs) may lay as much
> at the feet of the upstream developers as the downstream packagers
> (speaking as one who works on both sides).
Using package systems like `depot' or `stow', I haven't had any trouble
with any existing package. No need for special support from the
upstream developer.
> If the upstream hasn't
> ever considered the problem, then it can be very difficult, and
> require substantial hacking, to alter the upstream to handle multiple
> installed versions. This can be further hindered by the available OS
> and tools. For example, the fact that dlopen doesn't support
> versioning the way that ld.so does can make it difficult to allow
> multiply installed versions of software that relies on dlopened
> libraries, unless the upstream has considered that problem and chosen
> suitably unique library *names* for those libraries.
You don't need to change the name, just the directory in which to search for
the lib.
Stefan
^ permalink raw reply [flat|nested] 109+ messages in thread* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 14:53 ` Stefan Monnier
@ 2004-10-05 15:28 ` Rob Browning
2004-10-05 15:32 ` Rob Browning
0 siblings, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-10-05 15:28 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, Jerome Marant, emacs-devel, Kim F. Storm,
Miles Bader
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Just as it is possible if you don't use packages, it should be
> possible for the end user to decide that she wants to install Emacs
> versions 20.3, 20.4, 21.1, 21.2, and 21.3.
We probably could do that for many packages. Often it comes down to a
decision based on the available manpower as compared to the value of
providing additional revisions, though if all packages were to do it,
it might also come down a decision based on the load on the
infrastructure. It looks like we already provide over 15000 source
packages just in testing and unstable, and the number of actual
packages will be much more than that, related to the number of
architectures we support.
> Using package systems like `depot' or `stow', I haven't had any trouble
> with any existing package. No need for special support from the
> upstream developer.
OK, well for now, I'm not familiar enough with them to meaningfully
debate their merit as compared to apt, dpkg, and Debian's current
policies.
> You don't need to change the name, just the directory in which to
> search for the lib.
The problem is that then -L linking will fail unless ld.so has also
been augmented with these paths, or unless the user has added that
directory to their LD_LIBRARY_PATH. I'd still like to see dlpen
support for the algorithm that the normal linker uses, so you can tell
dlopen to open libbar version 4, and let it find the latest suitable
revision (i.e. the same one -L linking would find at runtime).
In any case, I suppose this is all somewhat off-topic. The only plea
I'd like to make is that if possible, Emacs use some versioning
strategy where there's at least one number or numbers that changes iff
substantial backward compatibility is introduced.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 15:28 ` Rob Browning
@ 2004-10-05 15:32 ` Rob Browning
2004-10-06 8:07 ` Kim F. Storm
0 siblings, 1 reply; 109+ messages in thread
From: Rob Browning @ 2004-10-05 15:32 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, Jerome Marant, emacs-devel, Kim F. Storm,
Miles Bader
Rob Browning <rlb@defaultvalue.org> writes:
> The only plea I'd like to make is that if possible, Emacs use some
> versioning strategy where there's at least one number or numbers
> that changes iff substantial backward compatibility is introduced.
Oh, and I wasn't trying to imply in the above that Emacs hasn't been
doing that. From at least the packaging perspective, my impression is
that so far, Emacs has.
--
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]
2004-10-05 15:32 ` Rob Browning
@ 2004-10-06 8:07 ` Kim F. Storm
0 siblings, 0 replies; 109+ messages in thread
From: Kim F. Storm @ 2004-10-06 8:07 UTC (permalink / raw)
Cc: Francesco Potorti`, rms, Jerome Marant, emacs-devel,
Stefan Monnier, Miles Bader
Rob Browning <rlb@defaultvalue.org> writes:
> Rob Browning <rlb@defaultvalue.org> writes:
>
>> The only plea I'd like to make is that if possible, Emacs use some
>> versioning strategy where there's at least one number or numbers
>> that changes iff substantial backward compatibility is introduced.
>
> Oh, and I wasn't trying to imply in the above that Emacs hasn't been
> doing that. From at least the packaging perspective, my impression is
> that so far, Emacs has.
>From a packaging point of view, 21.4 (or 22.1) includes the following:
** Leim is now part of the Emacs distribution.
You no longer need to download a separate tarball in order to build
Emacs with Leim.
** The Emacs Lisp Reference Manual is now part of the distribution.
** The Introduction to Programming in Emacs Lisp manual is now part of
the distribution.
** The `emacsserver' program has been removed, replaced with elisp code.
New Lisp packages included with emacs:
dns-mode, flymake, tree-widget, wdired thumbs, python, url, ido, cua,
kmacro, printing, calc, tramp, ruler-mode, ibuffer, table, ses,
syntax, gdb-ui, bindat, buttons, master-mode.
Updated packages: gnus, mh-e.
rmail will use mbox format rather than babyl (not on trunk yet).
Besides, emacs 21.4 can be biult with GTK+ support -- I don't know if
you would want to distribute two versions in Debian (with and without
GTK).
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 109+ messages in thread