* Updating release version to 22.1 @ 2005-02-08 13:06 Kim F. Storm 2005-02-08 13:34 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-08 13:06 UTC (permalink / raw) I already have made, but not installed, the necessary changes to update the trunk release version to 22.1. When we last discussed this issue, RMS said he preferred negative numbers for the CVS and pretest versions. So the CVS version will be updated to 22.1.-999, and pretests will be numbered 22.1.-998 , 22.1.-997 , etc. Unless someone strongly objects, I will install these changes later today (within the next 12 hours). -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 13:06 Updating release version to 22.1 Kim F. Storm @ 2005-02-08 13:34 ` David Kastrup 2005-02-08 14:46 ` Stefan Monnier 2005-02-08 15:05 ` Kim F. Storm 2005-02-09 16:08 ` DONE: " Kim F. Storm 2005-02-10 6:01 ` Richard Stallman 2 siblings, 2 replies; 36+ messages in thread From: David Kastrup @ 2005-02-08 13:34 UTC (permalink / raw) Cc: emacs-devel storm@cua.dk (Kim F. Storm) writes: > I already have made, but not installed, the necessary changes to > update the trunk release version to 22.1. > > When we last discussed this issue, RMS said he preferred negative > numbers for the CVS and pretest versions. > > So the CVS version will be updated to 22.1.-999, and pretests will be > numbered 22.1.-998 , 22.1.-997 , etc. > > Unless someone strongly objects, I will install these changes later > today (within the next 12 hours). Apart from my stomach turning at that convention, I believe that most version number comparison systems will be thwarted by the task of comparing the respective versions, and humans will be confused with the task of telling the versions apart. "Well, you said this was fixed in 22.1.-25, but I already have 22.1.-30 installed". Or, more seriously, "This was supposed to work starting with 22.1, and I already have 22.1.-30". Google searches ignore "-" signs, anyway, so looking for a particular version is going to throw in arbitrary preleases when searching for released packages. The numbering scheme may be geeky, but for all practical purposes it will cause trouble. Consider this a strong objection. I would appreciate getting at least the impression that the above reasons have registered before I get overridden. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 13:34 ` David Kastrup @ 2005-02-08 14:46 ` Stefan Monnier 2005-02-08 15:05 ` Kim F. Storm 1 sibling, 0 replies; 36+ messages in thread From: Stefan Monnier @ 2005-02-08 14:46 UTC (permalink / raw) Cc: emacs-devel, Kim F. Storm > the task of telling the versions apart. "Well, you said this was > fixed in 22.1.-25, but I already have 22.1.-30 installed". Or, more > seriously, "This was supposed to work starting with 22.1, and I > already have 22.1.-30". Google searches ignore "-" signs, anyway, so Agreed. In the past we've used the 22.0.90 style of versions and it has worked fine. I see no need to change it, Stefan ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 13:34 ` David Kastrup 2005-02-08 14:46 ` Stefan Monnier @ 2005-02-08 15:05 ` Kim F. Storm 2005-02-08 15:43 ` Han Boetes 2005-02-08 15:58 ` David Kastrup 1 sibling, 2 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-08 15:05 UTC (permalink / raw) Cc: emacs-devel David Kastrup <dak@gnu.org> writes: >> So the CVS version will be updated to 22.1.-999, and pretests will be >> numbered 22.1.-998 , 22.1.-997 , etc. >> > The numbering scheme may be geeky, but for all practical purposes it > will cause trouble. Consider this a strong objection. I would > appreciate getting at least the impression that the above reasons have > registered before I get overridden. We have discussed this before, and to the average user, our "current" scheme where the cvs version to be released as 21.4 is named 21.3.50 is also very confusing. I would much rather like to see some descriptive text in there, e.g. 22.1.DEV 22.1.PRE-1 22.1.PRE-2 etc. when working towards a release 22.1 Subsequent bug fixes could be named 22.1-1 So we could have 22.1-1.DEV 22.1-1.PRE-1 etc. WDYT? -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 15:05 ` Kim F. Storm @ 2005-02-08 15:43 ` Han Boetes 2005-02-08 16:24 ` David Kastrup 2005-02-08 15:58 ` David Kastrup 1 sibling, 1 reply; 36+ messages in thread From: Han Boetes @ 2005-02-08 15:43 UTC (permalink / raw) Since you want to release 22.1 the current code which is close to freeze, beta-phase, cleaning-up mode, should get version-number 22.0.90 which is consistent with 21.3.50. People will know it's 22.1 that's the upcoming release and more beta-testing is still needed, but the code is very usable if your live doesn't depend on it. So let the word spread: report any inconsistancy, spello, whatever you can find, preferably with a patch. # Han ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 15:43 ` Han Boetes @ 2005-02-08 16:24 ` David Kastrup 0 siblings, 0 replies; 36+ messages in thread From: David Kastrup @ 2005-02-08 16:24 UTC (permalink / raw) Han Boetes <han@mijncomputer.nl> writes: > Since you want to release 22.1 the current code which is close to > freeze, beta-phase, cleaning-up mode, should get version-number > 22.0.90 which is consistent with 21.3.50. People will know it's > 22.1 that's the upcoming release and more beta-testing is still > needed, but the code is very usable if your live doesn't depend on > it. > > So let the word spread: report any inconsistancy, spello, whatever > you can find, preferably with a patch. "preferably with a patch" would unfortunately be mostly a falsehood and unduly burdensome because of the copyright assignment policies we are forced to have. So it would usually be quite more important and helpful to have the trouble pinpointed rather than having a complete fix worked out. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 15:05 ` Kim F. Storm 2005-02-08 15:43 ` Han Boetes @ 2005-02-08 15:58 ` David Kastrup 2005-02-08 20:12 ` Kim F. Storm 1 sibling, 1 reply; 36+ messages in thread From: David Kastrup @ 2005-02-08 15:58 UTC (permalink / raw) Cc: emacs-devel storm@cua.dk (Kim F. Storm) writes: > David Kastrup <dak@gnu.org> writes: > >>> So the CVS version will be updated to 22.1.-999, and pretests will >>> be numbered 22.1.-998 , 22.1.-997 , etc. >>> >> The numbering scheme may be geeky, but for all practical purposes >> it will cause trouble. Consider this a strong objection. I would >> appreciate getting at least the impression that the above reasons >> have registered before I get overridden. > > We have discussed this before, and to the average user, our > "current" scheme where the cvs version to be released as 21.4 is > named 21.3.50 is also very confusing. I don't see how this would justify replacement with a scheme that is much more confusing. > I would much rather like to see some descriptive text in there, e.g. > > 22.1.DEV > > 22.1.PRE-1 > 22.1.PRE-2 > > etc. when working towards a release 22.1 I think that any suffix should not be separated by a period, but instead 22.1-pre1 would seem appropriate. When we are not particularly passing out something intended to be an approximation to a release, I'd rather have a version number numerically below the actual release, something like 21.3-dev20050301 though in our current case I think 22.0-dev20050301 as a precursor to 22.1 would seem a bit more intuitive. There is a lot of advice of the sort "will be supported in Emacs 21.4 or later", and "will be supported in Emacs 22" would give us better possibilities for being more or less accurate without having to eat our words too often. > Subsequent bug fixes could be named > > 22.1-1 That is not a good idea since the -%d tags are already used in many package systems (RPM/Debian) for tagging fixed packages (new configure options, different package layouts, packaging errors and so on). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 15:58 ` David Kastrup @ 2005-02-08 20:12 ` Kim F. Storm 2005-02-08 21:18 ` Jérôme Marant 0 siblings, 1 reply; 36+ messages in thread From: Kim F. Storm @ 2005-02-08 20:12 UTC (permalink / raw) Cc: emacs-devel David Kastrup <dak@gnu.org> writes: > I think that any suffix should not be separated by a period, but > instead 22.1-pre1 would seem appropriate. That is a good idea. Let's look at the possibilities: Type Emacs version With build number ---------------------------------------------------------- CVS 22.1-dev 22.1-dev.1 Pretest 22.1-pre1 22.1-pre1.1 Major Release 22.1 22.1.1 Bugfix 22.1.1 22.1.1.1 Minor 22.2 22.2.1 Bugfix 22.2.1 22.2.1.1 etc. This is unambiguous (you get the release version by stripping the last number), but still too confusing for my taste. But if we separate the build number with a dash too, it becomes clearer: Type Emacs version With build number ---------------------------------------------------------- CVS 22.1-dev 22.1-dev-1 Pretest 22.1-pre1 22.1-pre1-1 Major Release 22.1 22.1-1 Bugfix 22.1.1 22.1.1-1 Minor 22.2 22.2-1 Bugfix 22.2.1 22.2.1-1 But you say -%d should be avoided; to fix that and make it even clearer we can use a -bNNN suffix like this: Type Emacs version With build number ---------------------------------------------------------- CVS 22.1-dev 22.1-dev-b1 Pretest 22.1-pre1 22.1-pre1-b1 Major Release 22.1 22.1-b1 Bugfix 22.1.1 22.1.1-b1 Minor 22.2 22.2-b1 Bugfix 22.2.1 22.2.1-b1 -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 20:12 ` Kim F. Storm @ 2005-02-08 21:18 ` Jérôme Marant 2005-02-08 22:34 ` David Kastrup 2005-02-08 22:38 ` Miles Bader 0 siblings, 2 replies; 36+ messages in thread From: Jérôme Marant @ 2005-02-08 21:18 UTC (permalink / raw) storm@cua.dk (Kim F. Storm) writes: > David Kastrup <dak@gnu.org> writes: > >> I think that any suffix should not be separated by a period, but >> instead 22.1-pre1 would seem appropriate. > > That is a good idea. > > Let's look at the possibilities: > > > Type Emacs version With build number > ---------------------------------------------------------- > CVS 22.1-dev 22.1-dev.1 > Pretest 22.1-pre1 22.1-pre1.1 What's the rational for not using 22.0.x for development versions? It would be so much simpler ... Cheers, -- Jérôme Marant ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 21:18 ` Jérôme Marant @ 2005-02-08 22:34 ` David Kastrup 2005-02-08 22:38 ` Miles Bader 1 sibling, 0 replies; 36+ messages in thread From: David Kastrup @ 2005-02-08 22:34 UTC (permalink / raw) Cc: emacs-devel Jérôme Marant <jmarant@free.fr> writes: > storm@cua.dk (Kim F. Storm) writes: > >> David Kastrup <dak@gnu.org> writes: >> >>> I think that any suffix should not be separated by a period, but >>> instead 22.1-pre1 would seem appropriate. >> >> That is a good idea. >> >> Let's look at the possibilities: >> >> >> Type Emacs version With build number >> ---------------------------------------------------------- >> CVS 22.1-dev 22.1-dev.1 >> Pretest 22.1-pre1 22.1-pre1.1 > > What's the rational for not using 22.0.x for development versions? > It would be so much simpler ... Agreed. However, it would be a precursor to "version inflation" since it would mean that the trunk would generally be versioned something.0.x. For example, the internal unicode&multitty-version development would already be at least called 23.0.x. This runs contrary to the trend of conservative version numbers (for example, there does not seem to be _any_ incentive ever to get to 3.something with Linux kernels). However, given that we already are in the twenties (though having started as a teen, skipping childhood), this might be tolerable; it would not appear that we are much in a love affair with small numbers, anyhow. It would be my favorite scheme to start new major version numbers whenever we have ongoing feature development. This would have the advantage that "to be expected for Emacs 27" would usually remain more or less predictable as well as sufficiently rememberable. I can live with other schemes, but I _definitely_ want a scheme where I can tell people a) this feature will be present in version x b) this bug will be fixed in version y and not fall flat on my face by any necessitated intermediate releases. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 21:18 ` Jérôme Marant 2005-02-08 22:34 ` David Kastrup @ 2005-02-08 22:38 ` Miles Bader 2005-02-09 0:17 ` Kim F. Storm 1 sibling, 1 reply; 36+ messages in thread From: Miles Bader @ 2005-02-08 22:38 UTC (permalink / raw) Cc: emacs-devel On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@free.fr> wrote: > What's the rational for not using 22.0.x for development versions? > It would be so much simpler ... Seriously; all this random arguing over wacky scheme X or wacky scheme Y seems a bit odd in the face of such an obvious answer. Note that given Emacs' traditional numbering practices, it only works with "super major" release like 22.1 -- a minor release would need either some other scheme, or a change in the general versioning rules Emacs uses -- but do we really need to spend time bickering right now? [and judging from past threads on this issue, people _love_ to bicker over it.] Another comment on the wacky schemes: Debian uses a "-" separator in versions for their own reasons, and a "_" separator in package names, so it might be nice to avoid using these characters. They have designated the "~" to be used to denote "pre-versions", so if Emacs uses such a syntax, it might adopt this too, e.g.: "22.1~pre1" (the suffix always ~ sorts before even no suffix at all). -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 22:38 ` Miles Bader @ 2005-02-09 0:17 ` Kim F. Storm 2005-02-09 0:32 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 0:17 UTC (permalink / raw) Cc: emacs-devel, Jérôme Marant, miles Miles Bader <snogglethorpe@gmail.com> writes: > On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> wrote: >> What's the rational for not using 22.0.x for development versions? >> It would be so much simpler ... Because it - IMO - is confusing. Right now (or two days ago) we had released 21.3 and were working on the trunk towards a release 21.4. But the version on the trunk is numbered 21.3.50 Typically, the user who built 21.3 has a version called 21.3.1 or 21.3.2 which is pretty close to 21.3.50 But if we could agree that we always release major versions from the trunk and each major release gets a new major number 22.1, 23.1, etc, I see no problem using 22.0.0, 23.0.0, etc as development versions, ans 22.0.1, 22.0.2, etc for the pretests. Bug fixes would be released from branches, and be named 22.2, 22.3, etc. Looking at past history, this wont cause major number inflation -- if lucky, we will release 30.1 in 2030 which isn't too bad :-) That is indeed a simple scheme which I would support. So Richard, if we could agree that major releasees from the trunk always gets a new major number, we will get a simple numbering scheme without the risk of accidentally using a "reserved" release number as you just did. It would be MUCH LESS HASSLE for future work if we implemented this scheme right away. I'll wait until tomorrow until I install my changes for 22.1 (or 22.0.0) -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 0:17 ` Kim F. Storm @ 2005-02-09 0:32 ` David Kastrup 2005-02-09 1:21 ` Miles Bader 2005-02-10 6:01 ` Richard Stallman 2 siblings, 0 replies; 36+ messages in thread From: David Kastrup @ 2005-02-09 0:32 UTC (permalink / raw) Cc: miles, rms, Jérôme Marant, emacs-devel storm@cua.dk (Kim F. Storm) writes: > Miles Bader <snogglethorpe@gmail.com> writes: > >> On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> wrote: >>> What's the rational for not using 22.0.x for development versions? >>> It would be so much simpler ... > > Because it - IMO - is confusing. > > Right now (or two days ago) we had released 21.3 and were working on > the trunk towards a release 21.4. > > But the version on the trunk is numbered 21.3.50 > > Typically, the user who built 21.3 has a version called 21.3.1 or > 21.3.2 which is pretty close to 21.3.50 Ok, I forgot about _build_ numbers. Doing a quick locate, I find /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.30 /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.31 /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.32 Maybe _build_ numbers should be tagged off with -%d instead of .%d after all. Yes, this is the same numbering scheme that RPMs and other packages tend to use, but they use it for _exactly_ that purpose: to indicate build numbers (and it does not usually get reflected in an file names within the package). > But if we could agree that we always release major versions from the > trunk and each major release gets a new major number 22.1, 23.1, > etc, I see no problem using 22.0.0, 23.0.0, etc as development > versions, ans 22.0.1, 22.0.2, etc for the pretests. > > Bug fixes would be released from branches, and be named 22.2, 22.3, > etc. > > Looking at past history, this wont cause major number inflation -- > if lucky, we will release 30.1 in 2030 which isn't too bad :-) > > That is indeed a simple scheme which I would support. > > So Richard, if we could agree that major releasees from the trunk > always gets a new major number, we will get a simple numbering > scheme without the risk of accidentally using a "reserved" release > number as you just did. > > It would be MUCH LESS HASSLE for future work if we implemented this > scheme right away. Seconded. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 0:17 ` Kim F. Storm 2005-02-09 0:32 ` David Kastrup @ 2005-02-09 1:21 ` Miles Bader 2005-02-09 8:30 ` Kim F. Storm 2005-02-10 6:01 ` Richard Stallman 2 siblings, 1 reply; 36+ messages in thread From: Miles Bader @ 2005-02-09 1:21 UTC (permalink / raw) Cc: emacs-devel, rms, Jérôme Marant, miles On Wed, 09 Feb 2005 01:17:30 +0100, Kim F. Storm <storm@cua.dk> wrote: > > On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> wrote: > >> What's the rational for not using 22.0.x for development versions? > >> It would be so much simpler ... > > Because it - IMO - is confusing. What, compared to all the other bizarro schemes being suggested here ("hey I know, let's make pre-releases _blue_, and real releases _green_!")? You've got to be kidding... please say you're kidding... -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 1:21 ` Miles Bader @ 2005-02-09 8:30 ` Kim F. Storm 2005-02-09 8:41 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 8:30 UTC (permalink / raw) Cc: emacs-devel, rms, Jérôme Marant, miles Miles Bader <snogglethorpe@gmail.com> writes: > On Wed, 09 Feb 2005 01:17:30 +0100, Kim F. Storm <storm@cua.dk> wrote: >> > On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> wrote: >> >> What's the rational for not using 22.0.x for development versions? >> >> It would be so much simpler ... >> >> Because it - IMO - is confusing. > > What, compared to all the other bizarro schemes being suggested here > ("hey I know, let's make pre-releases _blue_, and real releases > _green_!")? You've got to be kidding... please say you're kidding... Not really! The problem with our _current_ scheme is that even though we seem to want to postpone the decision about exactly what number the next release gets, it is recorded _NUMEROUS_ places all over the sources and other files (in total, I had to change 21.4 to 22.1 in more than 500 places). I don't want us to get into that mess again -- so I want a scheme where the next release number is _fixed_ from the start. This is easily achieved by _always_ using MM.1 (MM = 22,23,24...) for releases from the trunk, and MM.N (N = 2,3,4...) for bugfixes from the release branch (RC_MM_1). Given that, it seems a little odd that the development version is called something different from MM.1-something... But ok, lets stick with 22.0.50 for now. My primary concern is if some code tests specifically for MM.1 in some way, e.g. "version >= MM.1" and the dev/pretest version is MM.0, then we may not see a specific error until we update the version to MM.1 and release the software -- without EVER testing that it works with the actual release number. Sadly code _does_ test version numbers! -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 8:30 ` Kim F. Storm @ 2005-02-09 8:41 ` Miles Bader 2005-02-09 11:23 ` Kim F. Storm 2005-02-09 14:21 ` Lennart Borgman 2005-02-09 9:44 ` Lute Kamstra 2005-02-09 10:45 ` David Kastrup 2 siblings, 2 replies; 36+ messages in thread From: Miles Bader @ 2005-02-09 8:41 UTC (permalink / raw) Cc: emacs-devel, rms, Jérôme Marant, miles On Wed, 09 Feb 2005 09:30:42 +0100, Kim F. Storm <storm@cua.dk> wrote: > Miles Bader <snogglethorpe@gmail.com> writes: > > > On Wed, 09 Feb 2005 01:17:30 +0100, Kim F. Storm <storm@cua.dk> wrote: > >> > On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> wrote: > >> >> What's the rational for not using 22.0.x for development versions? > >> >> It would be so much simpler ... > >> > >> Because it - IMO - is confusing. > > > > What, compared to all the other bizarro schemes being suggested here > > ("hey I know, let's make pre-releases _blue_, and real releases > > _green_!")? You've got to be kidding... please say you're kidding... > > Not really! > > The problem with our _current_ scheme is that even though we seem to want to > postpone the decision about exactly what number the next release gets, it > is recorded _NUMEROUS_ places all over the sources and other files > (in total, I had to change 21.4 to 22.1 in more than 500 places). > > I don't want us to get into that mess again -- so I want a scheme > where the next release number is _fixed_ from the start. I have no idea what you're talking about. The problems caused by the current "mess" (21.4 released to mean something else, 22.1 chosen for next release) would have happened regardless of what scheme was chosen (including all of your wacky ones), because what occured is that an extra real release was added in between the last real release and the designated next real release. No amount of futzing around with pre-release names would have changed that. The questions, as I understand it, are merely (1) how to call real releases, and (2) how to call pre-releases. For the next release at least, it's been decided that (1) will be "22.1"; what I understand Jérôme to have meant is that (2) in this case should be "22.0.x", where x = 1, 2, 3, ... -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 8:41 ` Miles Bader @ 2005-02-09 11:23 ` Kim F. Storm 2005-02-09 13:32 ` Robert J. Chassell 2005-02-10 18:39 ` Richard Stallman 2005-02-09 14:21 ` Lennart Borgman 1 sibling, 2 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 11:23 UTC (permalink / raw) Cc: emacs-devel, rms, Jérôme Marant, miles Miles Bader <snogglethorpe@gmail.com> writes: >> I don't want us to get into that mess again -- so I want a scheme >> where the next release number is _fixed_ from the start. > > I have no idea what you're talking about. Which part of the sentense is difficult to understand? > > The problems caused by the current "mess" (21.4 released to mean > something else, 22.1 chosen for next release) would have happened > regardless of what scheme was chosen (including all of your wacky > ones), Stefan suggested 2.5 years ago to name the trunk version 22.1. Your response was: > From: Miles Bader <miles@gnu.org> > In-Reply-To: <200207021509.g62F9l617691@rum.cs.yale.edu> > Message-ID: <87n0taupfw.fsf@tc-1-100.kawasaki.gol.ne.jp> > Date: 03 Jul 2002 00:20:19 +0900 > > "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes: > > We could simply decide that RC versions will be 21.1, 21.2, 21.3, 21.4 > > and the next trunk version will be 22.1 (at which point it will be on its > > own branch for 22.2, 22.3, 22.4, ...). > > No, that would be silly. Emacs has a good history of changes in the > major version number really meaning that major changes were made; we > shouldn't screw that up unless it's for a very good reason (and I > haven't seen one presented yet). > > -Miles Silly? > because what occured is that an extra real release was added in > between the last real release and the designated next real release. Some of us saw it coming -- and you called us silly. And now I'm called wacky. Nice vocabulary, Miles. > No amount of futzing around with pre-release names would have changed > that. True -- that's not the main issue. If you read my mail carefully, I'm discussing two issues: - preventing the current mess (always use MM.1 for trunk releases and MM.N (N > 1) for bug fixes from the RC_MM branch -- as Stefan wisely suggested back then. - finding a scheme for development and pretest naming that uses MM.1-something rather than _a completely different_ version number which MM.0-something is IMO. > The questions, as I understand it, are merely (1) how to call real > releases, and (2) how to call pre-releases. That's what I'm talking about! > > For the next release at least, it's been decided that (1) will be > "22.1"; what I understand Jérôme to have meant is that (2) in this > case should be "22.0.x", where x = 1, 2, 3, ... _IF_ we stick to 22.0-something for dev and pretest, I definitely prefer if we keep the current scheme of 22.0.50 and 22.0.90... rather than inventing something new. As I said, I'll use 22.0.50 when I change things later today. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 11:23 ` Kim F. Storm @ 2005-02-09 13:32 ` Robert J. Chassell 2005-02-09 13:59 ` David Kastrup 2005-02-09 14:15 ` Jason Rumney 2005-02-10 18:39 ` Richard Stallman 1 sibling, 2 replies; 36+ messages in thread From: Robert J. Chassell @ 2005-02-09 13:32 UTC (permalink / raw) Cc: miles, snogglethorpe, rms, jmarant, emacs-devel > because what occured is that an extra real release was added in > between the last real release and the designated next real release. Yes, consequently the designated next real release should be called 21.5. Put another way, all the arguments made in the past for incrementing the decimal digit after 21 still apply. Over the past few days, who has said that the contents of the new release will be much more than previously specified? -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 13:32 ` Robert J. Chassell @ 2005-02-09 13:59 ` David Kastrup 2005-02-09 14:15 ` Jason Rumney 1 sibling, 0 replies; 36+ messages in thread From: David Kastrup @ 2005-02-09 13:59 UTC (permalink / raw) Cc: rms, jmarant, emacs-devel, Kim F. Storm, snogglethorpe, miles "Robert J. Chassell" <bob@rattlesnake.com> writes: >> because what occured is that an extra real release was added in >> between the last real release and the designated next real release. > > Yes, consequently the designated next real release should be called > 21.5. Put another way, all the arguments made in the past for > incrementing the decimal digit after 21 still apply. Except that we now have the factual knowledge as well as the written explanation of Richard that there can be situations in which he will do a release without asking or telling anybody in advance, and these emergency releases will, in all likelihood due to his personal release scripts, carry the minor number incremented, and not be something like 21.4b or whatever. At the time where we discussed this last, there already had been considerable talk about 21.4, and the question was whether one should invalidate this without concrete reason. There has been no previous talk about 21.5, in contrast, and in view of the facts it would be foolish to make the same mistake again. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 13:32 ` Robert J. Chassell 2005-02-09 13:59 ` David Kastrup @ 2005-02-09 14:15 ` Jason Rumney 1 sibling, 0 replies; 36+ messages in thread From: Jason Rumney @ 2005-02-09 14:15 UTC (permalink / raw) Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 968 bytes --] Robert J. Chassell wrote: >> because what occured is that an extra real release was added in >>between the last real release and the designated next real release. >> >> > >Yes, consequently the designated next real release should be called >21.5. > RMS has already stated that the next release from the trunk will be 22.1, and I think most developers agree with him, so it is not a useful use of our time to continue discussing what the next release will be called. Discussing what the pre-release and development version will be called is marginally more useful, but I've yet to see anyone put forward a suggestion that does not have as many drawbacks as the current system, and it has wasted a lot of time now, so unless someone comes up with something new that they've thought through themselves first, then it must be about time to drop the discussion and stick with what we have, which while not perfect has suited us well enough until now. [-- Attachment #1.2: Type: text/html, Size: 1351 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 11:23 ` Kim F. Storm 2005-02-09 13:32 ` Robert J. Chassell @ 2005-02-10 18:39 ` Richard Stallman 2005-02-10 21:49 ` Kim F. Storm 1 sibling, 1 reply; 36+ messages in thread From: Richard Stallman @ 2005-02-10 18:39 UTC (permalink / raw) Cc: snogglethorpe, emacs-devel, jmarant, miles As I said, I'll use 22.0.50 when I change things later today. As my previous message on this topic says, I have not decided what scheme we will use for this. I mentioned two possible schemes that I think may be good. I am always a day behind in responding to my email. As a result, it can easily happen that you and a few other people have a quick discussion and reach an appearance of "agreement" before I see the beginning of it. Please don't presume I agree only because I have not had a chance to comment. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-10 18:39 ` Richard Stallman @ 2005-02-10 21:49 ` Kim F. Storm 2005-02-10 22:33 ` Jérôme Marant 0 siblings, 1 reply; 36+ messages in thread From: Kim F. Storm @ 2005-02-10 21:49 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > As I said, I'll use 22.0.50 when I change things later today. > > As my previous message on this topic says, I have not decided what > scheme we will use for this. I mentioned two possible schemes that I > think may be good. > > I am always a day behind in responding to my email. As a result, it > can easily happen that you and a few other people have a quick > discussion and reach an appearance of "agreement" before I see the > beginning of it. Please don't presume I agree only because I have not > had a chance to comment. Choosing a new numbering scheme has been discussed for years now, without making any decisions on what to do. So for the moment, I simply decided to use 22.0.50 for the CVS version as this is in accordance with the current numbering scheme, and all the relevant code assumes this convention. Adapting to whatever new scheme you decide to use will be trivial. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-10 21:49 ` Kim F. Storm @ 2005-02-10 22:33 ` Jérôme Marant 2005-02-10 22:52 ` David Kastrup 0 siblings, 1 reply; 36+ messages in thread From: Jérôme Marant @ 2005-02-10 22:33 UTC (permalink / raw) storm@cua.dk (Kim F. Storm) writes: > Choosing a new numbering scheme has been discussed for years now, > without making any decisions on what to do. > > So for the moment, I simply decided to use 22.0.50 for the CVS version > as this is in accordance with the current numbering scheme, and all > the relevant code assumes this convention. > > Adapting to whatever new scheme you decide to use will be trivial. But would probably require a dedicated version comparision algorithm to be implemented, which is a complete waste of time. Almost everyone agreed with using 22.0 because it is obviously simple and sane. Why trying to make things more complicated through a non-democratic decision? Cheers, -- Jérôme Marant ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-10 22:33 ` Jérôme Marant @ 2005-02-10 22:52 ` David Kastrup 0 siblings, 0 replies; 36+ messages in thread From: David Kastrup @ 2005-02-10 22:52 UTC (permalink / raw) Cc: emacs-devel Jérôme Marant <jerome.marant@free.fr> writes: > storm@cua.dk (Kim F. Storm) writes: > >> Choosing a new numbering scheme has been discussed for years now, >> without making any decisions on what to do. >> >> So for the moment, I simply decided to use 22.0.50 for the CVS >> version as this is in accordance with the current numbering scheme, >> and all the relevant code assumes this convention. >> >> Adapting to whatever new scheme you decide to use will be trivial. > > But would probably require a dedicated version comparision algorithm > to be implemented, which is a complete waste of time. > > Almost everyone agreed with using 22.0 because it is obviously > simple and sane. Why trying to make things more complicated through > a non-democratic decision? It is obvious that all that can be said about that matter has been said and more than that. There is no use debating this further until Richard has the time and means to catch up. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 8:41 ` Miles Bader 2005-02-09 11:23 ` Kim F. Storm @ 2005-02-09 14:21 ` Lennart Borgman 2005-02-09 14:56 ` Kim F. Storm 1 sibling, 1 reply; 36+ messages in thread From: Lennart Borgman @ 2005-02-09 14:21 UTC (permalink / raw) Cc: emacs-devel Maybe the effort of changing the version number should be saved to the CVS as some kind of script? ----- Original Message ----- From: "Miles Bader" <snogglethorpe@gmail.com> The problems caused by the current "mess" (21.4 released to mean something else, 22.1 chosen for next release) would have happened regardless of what scheme was chosen (including all of your wacky ones), because what occured is that an extra real release was added in between the last real release and the designated next real release. No amount of futzing around with pre-release names would have changed that. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 14:21 ` Lennart Borgman @ 2005-02-09 14:56 ` Kim F. Storm 0 siblings, 0 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 14:56 UTC (permalink / raw) Cc: emacs-devel, miles "Lennart Borgman" <lennart.borgman.073@student.lu.se> writes: > Maybe the effort of changing the version number should be saved to the CVS > as some kind of script? There is already M-x set-version to update the version number in _known_ places. I don't see how you can automate the task of updating it throughout. So I prefer to avoid the mess in the first place. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 8:30 ` Kim F. Storm 2005-02-09 8:41 ` Miles Bader @ 2005-02-09 9:44 ` Lute Kamstra 2005-02-09 10:54 ` Kim F. Storm 2005-02-09 10:45 ` David Kastrup 2 siblings, 1 reply; 36+ messages in thread From: Lute Kamstra @ 2005-02-09 9:44 UTC (permalink / raw) Cc: miles, snogglethorpe, rms, Jérôme Marant, emacs-devel storm@cua.dk (Kim F. Storm) writes: [...] > My primary concern is if some code tests specifically for MM.1 in some > way, e.g. "version >= MM.1" and the dev/pretest version is MM.0, then > we may not see a specific error until we update the version to MM.1 > and release the software -- without EVER testing that it works > with the actual release number. > > Sadly code _does_ test version numbers! Yup, I remember finding a bug with scrollbars on Irix when Emacs' version number was changed from 21.0.106 to 21.1. Maybe somebody can do a grep on the sources and double-check the uses of emacs-\(major\|minor\)-version? Code that in maintained within Emacs' CVS shouldn't have to use those variables (except as informative output for users). Lute. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 9:44 ` Lute Kamstra @ 2005-02-09 10:54 ` Kim F. Storm 0 siblings, 0 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 10:54 UTC (permalink / raw) Cc: miles, snogglethorpe, rms, Jérôme Marant, emacs-devel Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes: > storm@cua.dk (Kim F. Storm) writes: > > [...] > >> My primary concern is if some code tests specifically for MM.1 in some >> way, e.g. "version >= MM.1" and the dev/pretest version is MM.0, then >> we may not see a specific error until we update the version to MM.1 >> and release the software -- without EVER testing that it works >> with the actual release number. >> >> Sadly code _does_ test version numbers! > > Yup, I remember finding a bug with scrollbars on Irix when Emacs' > version number was changed from 21.0.106 to 21.1. So it is not just a theoritical concern, thanks! > Maybe somebody can do a grep on the sources and double-check the uses > of emacs-\(major\|minor\)-version? Code that in maintained within > Emacs' CVS shouldn't have to use those variables (except as > informative output for users). I agree in principle, and it goes for eliminating Xemacs specific code too. But we cannot do that in practice -- some maintainers want to keep compatibility with other dialects / older releases in the packages installed in CVS emacs. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 8:30 ` Kim F. Storm 2005-02-09 8:41 ` Miles Bader 2005-02-09 9:44 ` Lute Kamstra @ 2005-02-09 10:45 ` David Kastrup 2005-02-09 10:52 ` Miles Bader 2 siblings, 1 reply; 36+ messages in thread From: David Kastrup @ 2005-02-09 10:45 UTC (permalink / raw) Cc: miles, snogglethorpe, rms, Jérôme Marant, emacs-devel storm@cua.dk (Kim F. Storm) writes: > Miles Bader <snogglethorpe@gmail.com> writes: > >> On Wed, 09 Feb 2005 01:17:30 +0100, Kim F. Storm <storm@cua.dk> wrote: >>> > On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> wrote: >>> >> What's the rational for not using 22.0.x for development versions? >>> >> It would be so much simpler ... >>> >>> Because it - IMO - is confusing. >> >> What, compared to all the other bizarro schemes being suggested here >> ("hey I know, let's make pre-releases _blue_, and real releases >> _green_!")? You've got to be kidding... please say you're kidding... > > Not really! > > The problem with our _current_ scheme is that even though we seem to > want to postpone the decision about exactly what number the next > release gets, it is recorded _NUMEROUS_ places all over the sources > and other files (in total, I had to change 21.4 to 22.1 in more than > 500 places). That is not counting the 8000+ web pages containing Emacs-21.4... > I don't want us to get into that mess again -- so I want a scheme > where the next release number is _fixed_ from the start. This assumes that most version numbers in the text can stay ("will be available with version xxx" is a good candidate). That will still need to cater for "the current version is xxx", but maybe _those_ can partly be autogenerated with CVS keywords, depending on the kind of text? In AUCTeX, we have something like (eval-and-compile (defconst AUCTeX-version (eval-when-compile (let ((name "$Name: $") (rev "$Revision: 5.482 $")) (or (when (string-match "\\`[$]Name: *\\(release_\\)?\\([^ ]+\\) *[$]\\'" name) (setq name (match-string 2 name)) (while (string-match "_" name) (setq name (replace-match "." t t name))) name) (if (string-match "\\`[$]Revision: *\\([^ ]+\\) *[$]\\'" rev) (format "CVS-%s" (match-string 1 rev))) "unknown"))) "AUCTeX version. If not a regular release, CVS revision of `tex.el'.")) It's less than perfect, but at least it is something one can't forget. It also means that you need to export using the version tag when doing a release. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 10:45 ` David Kastrup @ 2005-02-09 10:52 ` Miles Bader 2005-02-09 11:33 ` Kim F. Storm 0 siblings, 1 reply; 36+ messages in thread From: Miles Bader @ 2005-02-09 10:52 UTC (permalink / raw) Cc: snogglethorpe, emacs-devel, rms, Jérôme Marant, Kim F. Storm David Kastrup <dak@gnu.org> writes: > This assumes that most version numbers in the text can stay ("will be > available with version xxx" is a good candidate). That will still > need to cater for "the current version is xxx", but maybe _those_ can > partly be autogenerated with CVS keywords, depending on the kind of > text? Certainly it would be better to use a variable than straight text where possible. But, please, no !@#$ cvs keywords (which have bugger-all connection to anything real anyway). Where do all these instances of release numbers occur anyway? (Kim?) Cases in lisp code obviously should refer to a lisp variable instead (emacs-version, emacs-next-major-release :-). Cases in help text or texinfo could possibly be addressed with some analogous mechanism. -Miles -- "1971 pickup truck; will trade for guns" ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 10:52 ` Miles Bader @ 2005-02-09 11:33 ` Kim F. Storm 0 siblings, 0 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 11:33 UTC (permalink / raw) Cc: Jérôme Marant, rms, snogglethorpe, emacs-devel Miles Bader <miles@lsi.nec.co.jp> writes: > David Kastrup <dak@gnu.org> writes: >> This assumes that most version numbers in the text can stay ("will be >> available with version xxx" is a good candidate). That will still >> need to cater for "the current version is xxx", but maybe _those_ can >> partly be autogenerated with CVS keywords, depending on the kind of >> text? > > Certainly it would be better to use a variable than straight text where > possible. But, please, no !@#$ cvs keywords (which have bugger-all > connection to anything real anyway). > > Where do all these instances of release numbers occur anyway? (Kim?) M-x grep RET 21\.4 * RET The majority comes from (defcustom ... :version "21.4") which certainly need to use a string constant. > > Cases in lisp code obviously should refer to a lisp variable instead > (emacs-version, emacs-next-major-release :-). (defcustom ... :version emacs-version) Ah, yes, really obvious? Oh you mean (defcustom ... :version emacs-version-21-4) that would work nicely. > > Cases in help text or texinfo could possibly be addressed with some > analogous mechanism. I'm sure there are just as obvious solutions for this too. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-09 0:17 ` Kim F. Storm 2005-02-09 0:32 ` David Kastrup 2005-02-09 1:21 ` Miles Bader @ 2005-02-10 6:01 ` Richard Stallman 2 siblings, 0 replies; 36+ messages in thread From: Richard Stallman @ 2005-02-10 6:01 UTC (permalink / raw) Cc: emacs-devel, jmarant, miles So Richard, if we could agree that major releasees from the trunk always gets a new major number, I see no need to be so rigid about such questions of methods. ^ permalink raw reply [flat|nested] 36+ messages in thread
* DONE: Updating release version to 22.1 2005-02-08 13:06 Updating release version to 22.1 Kim F. Storm 2005-02-08 13:34 ` David Kastrup @ 2005-02-09 16:08 ` Kim F. Storm 2005-02-09 16:32 ` David Kastrup 2005-02-09 17:39 ` Rob Browning 2005-02-10 6:01 ` Richard Stallman 2 siblings, 2 replies; 36+ messages in thread From: Kim F. Storm @ 2005-02-09 16:08 UTC (permalink / raw) storm@cua.dk (Kim F. Storm) writes: > I already have made, but not installed, the necessary changes to > update the trunk release version to 22.1. I have installed these changes: Change release version from 21.4 to 22.1 throughout. Change development version from 21.3.50 to 22.0.50. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: DONE: Updating release version to 22.1 2005-02-09 16:08 ` DONE: " Kim F. Storm @ 2005-02-09 16:32 ` David Kastrup 2005-02-09 17:39 ` Rob Browning 1 sibling, 0 replies; 36+ messages in thread From: David Kastrup @ 2005-02-09 16:32 UTC (permalink / raw) Cc: emacs-devel storm@cua.dk (Kim F. Storm) writes: > storm@cua.dk (Kim F. Storm) writes: > >> I already have made, but not installed, the necessary changes to >> update the trunk release version to 22.1. > > I have installed these changes: > > Change release version from 21.4 to 22.1 throughout. > > Change development version from 21.3.50 to 22.0.50. I have a release of preview-latex coming up the next days. Where this is an issue, I'll use a wording like "should be available with Emacs 22" now. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: DONE: Updating release version to 22.1 2005-02-09 16:08 ` DONE: " Kim F. Storm 2005-02-09 16:32 ` David Kastrup @ 2005-02-09 17:39 ` Rob Browning 1 sibling, 0 replies; 36+ messages in thread From: Rob Browning @ 2005-02-09 17:39 UTC (permalink / raw) Cc: emacs-devel storm@cua.dk (Kim F. Storm) writes: > I have installed these changes: > > Change release version from 21.4 to 22.1 throughout. > > Change development version from 21.3.50 to 22.0.50. As long as the convention that X.0.Y is a development pre-release is well-publicized, this seems like a reasonable convention. With respect to some of the other comments in this thread: - It would be perfectly fine as far as Debian' is concerned for you to use dashes in your version names, i.e. 22.0-pre22.1-3. (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version) Debian only presumes that its "revision" is what comes after the final dash (if any). (Using something like a 22.0 prefix would also mean that this version will still sort reasonably when 22.1 is finally released. Although Debian can always work around upstream numbering inconsistencies. That's what version epochs are for.) - Given the 22.0.50 approach above, what's the plan for *stable* pre-release versions? Say that 22.1 is the current release, and you need to make some tricky change for 22.3, tricky enough that you want to make an official pre-release for testing. (Perhaps that's not a viable scenario.) - I wonder if it might be helpful to separate out the "pre-release" status and make it official, i.e. have emacs-major-version, emacs-minor-version, *and* emacs-prerelease. The latter might be an integer for pre-releases and nil otherwise. This would allow you to programatically decide when to expose/hide the pre-release status. i.e. in display strings, you might want to show it, but most code would only want to look at major/minor. - It seems like the name used for a particular release might best depend on the context. Given the variable separation above, you might name the file emacs-22.1-pre4.tar.gz, have emacs-version report "GNU Emacs 22.1 (prerelease 4) ...", and have emacs-major, minor, and prerelease set to 22, 1, and 4 respectively. Then as mentioned, most important code would be acting on the values planned for the official release. Only code that needed to check for emacs-prerelease would, and the only real difference between the final (tested) pre-release and the official release would be (setq emacs-prerelease nil). - The now-defunct idea of naming the next major release 21.4 might have caused some problems for Debian and perhaps other distributions. This is because Debian allows people to install and run older "major" versions of emacs. Right now we have emacs20 and emacs21 (though emacs20 is about to be dropped), and the current system expects that installing a new version of emacsX won't break or change much. If 21.4 had been a major departue from 21.3, then we would have had to re-work our packaging so that instead of an emacs21 package, we'd have emacs21.4. We would also have had to change some internals. For example, the value of debian-emacs-flavor would have to be emacs21.4 rather than emacs21, and any add-on package's code that presumed that flavors wouldn't have a "." in them would be in trouble. This is probably not a huge concern for you, but I thought I'd mention it. 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] 36+ messages in thread
* Re: Updating release version to 22.1 2005-02-08 13:06 Updating release version to 22.1 Kim F. Storm 2005-02-08 13:34 ` David Kastrup 2005-02-09 16:08 ` DONE: " Kim F. Storm @ 2005-02-10 6:01 ` Richard Stallman 2 siblings, 0 replies; 36+ messages in thread From: Richard Stallman @ 2005-02-10 6:01 UTC (permalink / raw) Cc: emacs-devel When we last discussed this issue, RMS said he preferred negative numbers for the CVS and pretest versions. So the CVS version will be updated to 22.1.-999, and pretests will be numbered 22.1.-998 , 22.1.-997 , etc. Even better would be 22.1.-1.0, 22.1.-1.1, etc. That series has no finite bound. However, the dash could be a problem. Our convention in file names is to use dashes between version numbers, so dashes should not be part of version numbers. Using numbers such as 22.0.XX before 22.1, and 22.3.0.XX before 22.3, might be best. I would much rather like to see some descriptive text in there, e.g. 22.1.DEV 22.1.PRE-1 22.1.PRE-2 If we get rid of the dashes, this becomes like the previous idea exceptr with PRE instead of 0. I am not sure if using words like PRE would cause any problems. Subsequent bug fixes could be named 22.1-1 The dash is not clear in meaning--1-1 is not a number, so what is the version number? And it could cause confusion in file names. I would rather call the bug fix releases 22.2, etc., as in the past. ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2005-02-10 22:52 UTC | newest] Thread overview: 36+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-02-08 13:06 Updating release version to 22.1 Kim F. Storm 2005-02-08 13:34 ` David Kastrup 2005-02-08 14:46 ` Stefan Monnier 2005-02-08 15:05 ` Kim F. Storm 2005-02-08 15:43 ` Han Boetes 2005-02-08 16:24 ` David Kastrup 2005-02-08 15:58 ` David Kastrup 2005-02-08 20:12 ` Kim F. Storm 2005-02-08 21:18 ` Jérôme Marant 2005-02-08 22:34 ` David Kastrup 2005-02-08 22:38 ` Miles Bader 2005-02-09 0:17 ` Kim F. Storm 2005-02-09 0:32 ` David Kastrup 2005-02-09 1:21 ` Miles Bader 2005-02-09 8:30 ` Kim F. Storm 2005-02-09 8:41 ` Miles Bader 2005-02-09 11:23 ` Kim F. Storm 2005-02-09 13:32 ` Robert J. Chassell 2005-02-09 13:59 ` David Kastrup 2005-02-09 14:15 ` Jason Rumney 2005-02-10 18:39 ` Richard Stallman 2005-02-10 21:49 ` Kim F. Storm 2005-02-10 22:33 ` Jérôme Marant 2005-02-10 22:52 ` David Kastrup 2005-02-09 14:21 ` Lennart Borgman 2005-02-09 14:56 ` Kim F. Storm 2005-02-09 9:44 ` Lute Kamstra 2005-02-09 10:54 ` Kim F. Storm 2005-02-09 10:45 ` David Kastrup 2005-02-09 10:52 ` Miles Bader 2005-02-09 11:33 ` Kim F. Storm 2005-02-10 6:01 ` Richard Stallman 2005-02-09 16:08 ` DONE: " Kim F. Storm 2005-02-09 16:32 ` David Kastrup 2005-02-09 17:39 ` Rob Browning 2005-02-10 6:01 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.