Emacs Versions: major, minor and ...?

Emacs Versions: major, minor and ...?

[Colin Baxter]

The current emacs development version is "28.0.5". I know that "28" is
the value of the emacs-major-version variable and "0" is the value of
the emacs-minor-version variable. I assume "5" is also the value of a
variable, but what's its name?

Best wishes,

Colin Baxter.

Re: Emacs Versions: major, minor and ...?

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Date: Sat, 26 Jun 2021 19:05:55 +0100
> 
> The current emacs development version is "28.0.5".

You mean, "28.0.50", right?

> I know that "28" is the value of the emacs-major-version variable
> and "0" is the value of the emacs-minor-version variable. I assume
> "5" is also the value of a variable, but what's its name?

It's not a variable.  The version string comes from configure.ac, see
AC_INIT there.

Re: Emacs Versions: major, minor and ...?

[Colin Baxter]

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

    >> From: Colin Baxter <m43cap@yandex.com> Date: Sat, 26 Jun 2021
    >> 19:05:55 +0100
    >> 
    >> The current emacs development version is "28.0.5".

    > You mean, "28.0.50", right?

Yes.

    >> I know that "28" is the value of the emacs-major-version variable
    >> and "0" is the value of the emacs-minor-version variable. I
    >> assume "5" is also the value of a variable, but what's its name?

    > It's not a variable.  The version string comes from configure.ac,
    > see AC_INIT there.

Thanks. I see the AC_INIT contains the whole emacs-version dotted string
28.0.50 and not just the last two digits.

Re: Emacs Versions: major, minor and ...?

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Cc: help-gnu-emacs@gnu.org
> Cc: 
> Date: Sat, 26 Jun 2021 20:38:27 +0100
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     > It's not a variable.  The version string comes from configure.ac,
>     > see AC_INIT there.
> 
> Thanks. I see the AC_INIT contains the whole emacs-version dotted string
> 28.0.50 and not just the last two digits.

Yes, and it is the source for the other version-related variables.

Re: Emacs Versions: major, minor and ...?

[mrf]

Colin Baxter writes:

> The current emacs development version is "28.0.5". I know that "28" is
> the value of the emacs-major-version variable and "0" is the value of
> the emacs-minor-version variable. I assume "5" is also the value of a
> variable, but what's its name?

The third number after the dots is called micro or in some projects
patch, please take a look at semantic versioning (semver.org) and the
book (Producing Open Source Software by karl fogel)<free and gratis
book> despite the name of this book the author (karl fogel) is
mentioning the relation between free software and open source and uses
the term to describe same thing, anyway this book explain at chapter 7
the naming practices in software development.

In addition take look at the section that describe even/odd
(stable/unstable) strategy:

https://producingoss.com/en/development-cycle.html

BTW This is basic software engineering issue.

Re: Emacs Versions: major, minor and ...?

[Stefan Monnier via Users list for the GNU Emacs text editor]

mrf [2021-06-28 06:56:20] wrote:
> Colin Baxter writes:
>> The current emacs development version is "28.0.5". I know that "28" is
>> the value of the emacs-major-version variable and "0" is the value of
>> the emacs-minor-version variable. I assume "5" is also the value of a
>> variable, but what's its name?
> The third number after the dots is called micro or in some projects
> patch, please take a look at semantic versioning (semver.org) and the

Note that Emacs does not use semantic versioning.
Emacs release versions have the shape NN.MM and nothing more.

Emacs code that's not released has versions of the form NN.MM.OO where
OO can be 50 to mean "this is the code we're working on that will
hopefully become NN.MM+1", or it can be a of the form 9x (or 99x or 999x
..., tho I seem to remember we've also used a sequence like 98, 99, 100,
101 at some point) for pretest versions (basically beta-releases) of
NN.MM+1.

[ In the past, Emacs *executables* had versions numbers of the form
  NN.MM.BB (or NN.MM.OO.BB for non-release versions) where BB was a "build
  number", i.e. something that gets incremented every time the user builds
  Emacs again from the same directory.  We're not using that any
  more, tho.  ]


        Stefan

Re: Emacs Versions: major, minor and ...?

[Colin Baxter]

>>>>> mrf  <joinlaw@cock.li> writes:

    > Colin Baxter writes:

    >> The current emacs development version is "28.0.5". I know that
    >> "28" is the value of the emacs-major-version variable and "0" is
    >> the value of the emacs-minor-version variable. I assume "5" is
    >> also the value of a variable, but what's its name?

    > The third number after the dots is called micro or in some
    > projects patch, please take a look at semantic versioning
    > (semver.org) and the book (Producing Open Source Software by karl
    > fogel)<free and gratis
    book> despite the name of this book the author (karl fogel) is
    > mentioning the relation between free software and open source and
    > uses the term to describe same thing, anyway this book explain at
    > chapter 7 the naming practices in software development.

    > In addition take look at the section that describe even/odd
    > (stable/unstable) strategy:

    > https://producingoss.com/en/development-cycle.html

    > BTW This is basic software engineering issue.

Thanks for the information, even if in this particular case it's not
directly appropriate for emacs.

Best wishes,

Re: Emacs Versions: major, minor and ...?

[Colin Baxter]

>>>>> Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:

    > mrf [2021-06-28 06:56:20] wrote:
    >> Colin Baxter writes:
    >>> The current emacs development version is "28.0.5". I know that
    >>> "28" is the value of the emacs-major-version variable and "0" is
    >>> the value of the emacs-minor-version variable. I assume "5" is
    >>> also the value of a variable, but what's its name?
    >> The third number after the dots is called micro or in some
    >> projects patch, please take a look at semantic versioning
    >> (semver.org) and the

    > Note that Emacs does not use semantic versioning.  Emacs release
    > versions have the shape NN.MM and nothing more.

    > Emacs code that's not released has versions of the form NN.MM.OO
    > where OO can be 50 to mean "this is the code we're working on that
    > will hopefully become NN.MM+1", or it can be a of the form 9x (or
    > 99x or 999x ..., tho I seem to remember we've also used a sequence
    > like 98, 99, 100, 101 at some point) for pretest versions
    > (basically beta-releases) of NN.MM+1.

    > [ In the past, Emacs *executables* had versions numbers of the
    > form NN.MM.BB (or NN.MM.OO.BB for non-release versions) where BB
    > was a "build number", i.e. something that gets incremented every
    > time the user builds Emacs again from the same directory.  We're
    > not using that any more, tho.  ]

Thank you for the information. In centuries to come, no doubt someone will
write a thesis unravelling the arcane numbering in emacs versions.

Best wishes,

Colin Baxter.

Re: Emacs Versions: major, minor and ...?

[mrf]

Stefan Monnier via Users list for the GNU Emacs text editor writes:

> [ In the past, Emacs *executables* had versions numbers of the form
>   NN.MM.BB (or NN.MM.OO.BB for non-release versions) where BB was a "build
>   number", i.e. something that gets incremented every time the user builds
>   Emacs again from the same directory.  We're not using that any
>   more, tho.  ]
>
>
>         Stefan

Nice! and by the way I was talking in general not in relation to emacs
so I mention karl fogel book where he also discuss that technique to
append build number or hash.

Re: Emacs Versions: major, minor and ...?

[Emanuel Berg via Users list for the GNU Emacs text editor]

mrf wrote:

> The third number after the dots is called micro or in some
> projects patch

Yes, major.minor.patch is what I've heard, I guess
major.minor.micro is more logical but it is always (sometimes)
good with a style change at the end, it makes it
more interesting.

The problem with this scheme is where do you draw the line
between these three things, exactly?

Maybe one could instead base it on what actually happens with
the software, e.g.

  module.feature.fix

where module and feature would represent new additions, while
fix would be bugfixes and organizational/cosmetic
improvements...

A simpler way where you don't have to think about this at all
is to have the version equal the date and time of the
last change. Only then, when one offers support for a piece of
software, for example on a mailing list/newsgroup such as
this, one would just assume everyone is always using the
latest version. I don't know, maybe it would depend from
situation to situation if that would be a good thing or not?

> In addition take look at the section that describe even/odd
> (stable/unstable) strategy

I always wondered about that, how do you know if it is stable
or not? Unstable is easier because then one can just do
whatever and say it is unstable - and the word "unstable" does
include all cases when it is stable as well, right? - but how
can one tell if it is stable or not? Is there a different
process, some method in particular, or has it just been "out
there" for some specified period of time, and after that one
assumes its bugs have been found and rooted out?

-- 
underground experts united
https://dataswamp.org/~incal

[OFFTOPIC] Semver (was: Emacs Versions: major, minor and ...?)

[Stefan Monnier via Users list for the GNU Emacs text editor]

[ Retitled to clarify we're not talking about Emacs versions.  ]

> Yes, major.minor.patch is what I've heard, I guess
> major.minor.micro is more logical but it is always (sometimes)
> good with a style change at the end, it makes it
> more interesting.
>
> The problem with this scheme is where do you draw the line
> between these three things, exactly?

It's simple and clear:

- "micro/patch" changes preserve both forward and backward compatibility.

- "minor" changes break forward compatible but not backward compatibility.

- "major" changes break both forward and backward compatibility.


        Stefan

Re: [OFFTOPIC] Semver (was: Emacs Versions: major, minor and ...?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> It's simple and clear:
>
> - "micro/patch" changes preserve both forward and
> backward compatibility.
>
> - "minor" changes break forward compatible but not
> backward compatibility.
>
> - "major" changes break both forward and
> backward compatibility.

OK, that's a good definition, backward compatibility I think
one can understand just be thinking about it, if some version
n + 1 is backward compatible then everything that worked for
version n will also work for n + 1.

And forward compatibility, that's the same thing, only instead
of looking backwards, we look into the future, so for the
forward compatible version n + 1 everything that works for
that will also work for version n + 2 (if that's backward
compatible, I suppose the assumption must be?).

But what does that really mean? The second paragraph, I mean?
And how do you know when that happens or doesn't happen?

Backward compatibility, remove something that the old software
relied upon, or change the interface somewhere, e.g.
shuffle around the arguments of some function (yeah, one
shouldn't do that) then the old stuff won't work, so it isn't
backward compatible.

But what do you do to preserve/break forward compatibility?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [OFFTOPIC] Semver

[Stefan Monnier via Users list for the GNU Emacs text editor]

> But what do you do to preserve/break forward compatibility?

Strictly speaking, any change to the code can break something somewhere
(https://xkcd.com/1172/), but the general rule to preserve forward
compatibility is "don't introduce new features".

You can preserve forward compatibility while breaking backward
compatibility, e.g. by making a release that adds no new features but
drops support for old features (e.g. making the code more efficient
along the way).


        Stefan

Re: [OFFTOPIC] Semver

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> But what do you do to preserve/break forward compatibility?
>
> Strictly speaking, any change to the code can break
> something somewhere

Yes...

> but the general rule to preserve forward compatibility is
> "don't introduce new features".

Okay? I couldn't have guessed that... hm, how does it work
out? Ah, no new features -> major stays the same! But that's
"forward" only with respect to minor.micro/patch or what?

> You can preserve forward compatibility while breaking backward
> compatibility, e.g. by making a release that adds no new features but
> drops support for old features (e.g. making the code more efficient
> along the way).

So, new features -> major, drop support -> minor (forward
OK but not backward), and bugfix -> micro/patch (forward OK,
backward OK) ?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [OFFTOPIC] Semver

[Yuri Khan]

On Tue, 6 Jul 2021 at 04:30, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> >> But what do you do to preserve/break forward compatibility?
> >
> > Strictly speaking, any change to the code can break
> > something somewhere
> > but the general rule to preserve forward compatibility is
> > "don't introduce new features".

> So, new features -> major, drop support -> minor (forward
> OK but not backward), and bugfix -> micro/patch (forward OK,
> backward OK) ?

No, you’ve got it backward.

When we say “version 4.5 is backward-compatible with 4.2”, we mean
“Any software that works correctly with our version 4.2 will also work
correctly with version 4.5”. This means no features were removed that
you’d miss if you upgrade, and no incompatible changes have been
introduced (but some new features may have been added).

When we say “version 4.5.3 is forward-compatible with 4.5.1”, we mean
“Any software that works with 4.5.3 will also work with 4.5.1”. This
means there are no new features in 4.5.3 that you’d miss if you
downgrade (except that you may encounter old bugs).

Bug fixes only: increment patch, compatible both ways.
Feature additions: increment minor, backward compatibility only.
Feature removals: increment major, no compatibility guaranteed.
Dependent software must review changes and integration notes before
upgrading.

Re: [OFFTOPIC] Semver

[Emanuel Berg via Users list for the GNU Emacs text editor]

Yuri Khan wrote:

>>>> But what do you do to preserve/break forward compatibility?
>>>
>>> Strictly speaking, any change to the code can break
>>> something somewhere
>>> but the general rule to preserve forward compatibility is
>>> "don't introduce new features".
>>
>> So, new features -> major, drop support -> minor (forward
>> OK but not backward), and bugfix -> micro/patch (forward OK,
>> backward OK) ?
>
> No, you’ve got it backward.

OK, but if minor should be "forward not OK, backward OK" that
means it can't be update when drop stuff, only when you add
stuff, the the supposedly major number will keep track of
that... Wow, I'm soo excited to get the new version 2.0.0,
I wonder what stuff they have dropped??

> When we say “version 4.5 is backward-compatible with 4.2”, we mean
> “Any software that works correctly with our version 4.2 will also work
> correctly with version 4.5”. This means no features were removed that
> you’d miss if you upgrade, and no incompatible changes have been
> introduced [...]

Yes.

> When we say “version 4.5.3 is forward-compatible with
> 4.5.1”, we mean “Any software that works with 4.5.3 will
> also work with 4.5.1”.

OK, but on that level by definition everything is compatible
with everything, right?

> Bug fixes only: increment patch, compatible both ways
> Feature additions: increment minor, backward compatibility only
> Feature removals: increment major, no compatibility guaranteed

Bummer. I see why people don't use this :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [OFFTOPIC] Semver

[Yuri Khan]

On Tue, 6 Jul 2021 at 16:57, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:


> OK, but if minor should be "forward not OK, backward OK" that
> means it can't be update when drop stuff, only when you add
> stuff, the the supposedly major number will keep track of
> that... Wow, I'm soo excited to get the new version 2.0.0,
> I wonder what stuff they have dropped??

Yeah exactly. When you see a new major version in a semantically
versioned program/library, the emotion you feel is not excitement but
anxiety: what did they break this time? Is it something I was attached
to?

Of course, from the maintainer’s side, the situation is reversed:
“Woo! 57.0, we can finally drop that legacy API we’ve had to support
for the last several years, and that has been holding us back from
refactoring a whole subsystem because that would break every user of
that API!”

> > When we say “version 4.5.3 is forward-compatible with
> > 4.5.1”, we mean “Any software that works with 4.5.3 will
> > also work with 4.5.1”.
>
> OK, but on that level by definition everything is compatible
> with everything, right?

You mean, on the level of only patch number change? Should be, yes.
That’s why feature additions increment the minor version component.

Re: [OFFTOPIC] Semver

[Emanuel Berg via Users list for the GNU Emacs text editor]

Yuri Khan wrote:

> Of course, from the maintainer’s side, the situation is
> reversed: “Woo! 57.0, we can finally drop that legacy API
> we’ve had to support for the last several years, and that
> has been holding us back from refactoring a whole subsystem
> because that would break every user of that API!”

OK, good point, I didn't think of that, well, I hope the
devels write software because they enjoy it, true, but more
than that that they do it for the users - but then remember
that the devel is also the user a lot of the time, maybe more
so than the regular user, often. It is like collective egoism,
which is good.

But because there are more users than developers, when in
doubt one should try to make the users happy, even with small
things like the version number!

No, ha j/k :) I just don't feel stoked about the semantic
x.y.z anymore - but it was an interesting concept to learn
about, thank you guys.

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: [OFFTOPIC] Semver

[Drew Adams]

> Yeah exactly. When you see a new major version in a semantically
> versioned program/library, the emotion you feel is not excitement but
> anxiety: what did they break this time? Is it something I was attached
> to?
> 
> Of course, from the maintainer’s side, the situation is reversed:
> “Woo! 57.0, we can finally drop that legacy API we’ve had to support
> for the last several years, and that has been holding us back from
> refactoring a whole subsystem because that would break every user of
> that API!”

This.

On the other hand, with free software one can
usually expect that the maintainers are also users. ;-)