Updating release version to 22.1

Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[David Kastrup]

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

Re: Updating release version to 22.1

[Stefan Monnier]

> 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

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Han Boetes]

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

Re: Updating release version to 22.1

[David Kastrup]

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

Re: Updating release version to 22.1

[David Kastrup]

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

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Jérôme Marant]

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

Re: Updating release version to 22.1

[David Kastrup]

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

Re: Updating release version to 22.1

[Miles Bader]

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.

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[David Kastrup]

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

Re: Updating release version to 22.1

[Miles Bader]

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.

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Miles Bader]

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.

Re: Updating release version to 22.1

[Lute Kamstra]

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.

Re: Updating release version to 22.1

[David Kastrup]

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

Re: Updating release version to 22.1

[Miles Bader]

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"

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Robert J. Chassell]

>        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

Re: Updating release version to 22.1

[David Kastrup]

"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

Re: Updating release version to 22.1

[Jason Rumney]

[-- 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

Re: Updating release version to 22.1

[Lennart Borgman]

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.

Re: Updating release version to 22.1

[Kim F. Storm]

"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

DONE: Updating release version to 22.1

[Kim F. Storm]

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

Re: DONE: Updating release version to 22.1

[David Kastrup]

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

Re: DONE: Updating release version to 22.1

[Rob Browning]

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

Re: Updating release version to 22.1

[Richard Stallman]

    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.

Re: Updating release version to 22.1

[Richard Stallman]

    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.

Re: Updating release version to 22.1

[Richard Stallman]

    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.

Re: Updating release version to 22.1

[Kim F. Storm]

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

Re: Updating release version to 22.1

[Jérôme Marant]

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

Re: Updating release version to 22.1

[David Kastrup]

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