Version naming

Version naming

[Stefan Monnier]

OK, here's one of the favorite discussion topics.

So I'll keep it short to get the discussion started:

   The next release from trunk will be called 25.1 rather than 24.5

There, I said it.  For completeness, here's the motivation:
In retrospect 24.3 should have been named 25.1 and 24.4 should have been
named 26.1.  The ".N" thingy should really be kept only for bug-fix
releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
bug-fix releases.

I'll stop listening to this thread starting right about now, but don't
let that stop you wasting your time debating at length about this boring
subject,


        Stefan

RE: Version naming

[Drew Adams]

> 24.4 should have been named 26.1.

"Should have been"?  24.4 does not yet exist - it has not been
released.

The baby is not born.  Why regret having in mind the wrong
name?  It is still gestating, with a shipload of regressions
and other bugs.

Re: Version naming

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Mon, 29 Sep 2014 13:19:08 -0400

   So I'll keep it short to get the discussion started:

      The next release from trunk will be called 25.1 rather than 24.5

Cool.

   There, I said it.  For completeness, here's the motivation: In
   retrospect 24.3 should have been named 25.1 and 24.4 should
   have been named 26.1.  The ".N" thingy should really be kept
   only for bug-fix releases and neither of 24.3, 24.4, nor the
   previously planned 24.5 are bug-fix releases.

You should write all this in admin/notes/versioning, or somesuch.
That way, the need (or rather, people's desire) for this...

   I'll stop listening to this thread starting right about now,
   but don't let that stop you wasting your time debating at
   length about this boring subject,

...can be much reduced.  A repo'd document also has the advantage
of providing an evolvable base for attaching labels (such as
"stable", "bugfix", etc), the most likely-to-succeed way out of
the next rat's nest (i.e., preferred/"official" Emacs-under-Git
branch discipline/manglement/workflow) discussion.  Just watch!

I say "you should" as a shorthand for "we should, and i (in my own
crass and clumsy way) will do so RSN if someone who has more
impact doesn't beat me to it".  (In this case, RSN == one week.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Version naming

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> OK, here's one of the favorite discussion topics.
>
> So I'll keep it short to get the discussion started:
>
>    The next release from trunk will be called 25.1 rather than 24.5
>
> There, I said it.  For completeness, here's the motivation:
> In retrospect 24.3 should have been named 25.1 and 24.4 should have been
> named 26.1.  The ".N" thingy should really be kept only for bug-fix
> releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
> bug-fix releases.

That's a bit like the naming scheme Emacs had between version 1 and 18,
isn't it?

The numbering doesn't really matter, but I think it was kinda nice when
the major version number was only bumped on really big-ish transitions.
(I.e., mule, utf8, static binding...)

But, of course, the next Emacs release has eww, and that's a major
thing.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Version naming

[Ted Zlatanov]

On Tue, 30 Sep 2014 16:13:40 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> But, of course, the next Emacs release has eww, and that's a major
LMI> thing.  >"?

"Emacs Web Edition"

Ted

Re: Version naming

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

() Thien-Thi Nguyen <ttn@gnu.org>
() Tue, 30 Sep 2014 09:03:12 +0200

   shorthand for [...] RSN

I've just added admin/versioning.
I hope people will refine it.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Version naming

[Glenn Morris]

Thien-Thi Nguyen wrote:

> () Thien-Thi Nguyen <ttn@gnu.org>
> () Tue, 30 Sep 2014 09:03:12 +0200
>
>    shorthand for [...] RSN
>
> I've just added admin/versioning.

I don't really know what the point of that is. Who is it for?
Also it seems a rather long-winded, unclear summary of what Stefan said,
which boils down to:

   the ".N" thingy should really be kept only for bug-fix releases

Re: Version naming

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

() Glenn Morris <rgm@gnu.org>
() Fri, 10 Oct 2014 20:28:32 -0400

   Who is it for?

It's for anyone who would rather write this kind of stuff:
         
      the ".N" thingy should really be kept only for bug-fix
      releases

down than discuss (or watch discussed) the matter at length
(and often circularly) on mailing lists.  Maybe i stand alone
in this set, but i doubt it.

It's also for Org Mode hackers, as another "test document".
Granted, it doesn't exercise much of Org Mode at the moment,
but who knows what coolness may arise given the opportunity.
(A cursory M-x find-grep doesn't reveal other Org Mode files
under admin/, so i might be missing something.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Version naming

[Jens K. Loewe]

Stefan Monnier schrob am 29. Sep. 2014 um 13:19 Uhr dies:

> There, I said it.  For completeness, here's the motivation:
> In retrospect 24.3 should have been named 25.1 and 24.4 should have been
> named 26.1.  The ".N" thingy should really be kept only for bug-fix
> releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
> bug-fix releases.

Looking forward to Emacs 72 by the end of 2015.


-- 
I could contain traces of nuts.

Re: Version naming

[Glenn Morris]

Sorry, I found it hard to read, so I rewrote it to be prosaic.

Re: Version naming

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

() Glenn Morris <rgm@gnu.org>
() Wed, 15 Oct 2014 03:13:40 -0400

   Sorry, I found it hard to read, so I rewrote it to be prosaic.

No worries -- looks good.  Thanks.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Version naming

[Rob Browning]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The numbering doesn't really matter, but I think it was kinda nice when
> the major version number was only bumped on really big-ish transitions.
> (I.e., mule, utf8, static binding...)

That's how we've taken it in Debian at least (and derivatives), which
has allowed simultaneous installs (say emacs19 and emacs20), etc.

As a result, on the Debian side, each major increment does represent
more work: increased load on the mirrors, administrative overhead of
package migrations, removals, etc.

While that certainly shouldn't unduly influence the upstream decisions
here, I thought I'd mention it for reference.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Version naming

[Stefan Monnier]

> As a result, on the Debian side, each major increment does represent
> more work: increased load on the mirrors, administrative overhead of
> package migrations, removals, etc.

The real underlying cause is dpkg's inability to handle simultaneous
installs of different versions of the same package.  As a result, you
get more work, as you point out, and I can't easily keep around all the
versions I'd like to keep.


        Stefan

Re: Version naming

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The real underlying cause is dpkg's inability to handle simultaneous
 > installs of different versions of the same package.  As a result, you
 > get more work, as you point out, and I can't easily keep around all the
 > versions I'd like to keep.

I don't know if Debian would be willing to make official packages with
relocatable installations (ie, /opt-style installation aka application
bundle) but that would help solve the problem (up to conflicting
external dependencies, but I doubt Emacs has many "must equal x.YY"
dependencies).  I don't do it any more (running in-place is easier)
but I did experiment with it successfully a while back for locally
created dpkgs of XEmacs.

The idea is basically that you can have a complete set of
{bin,etc,lib,man,share} trees under /opt/local/emacs-x.yy (ie, the
arch-dependent files would end up in
/opt/local/emacs-x.yy/lib/emacs-x.yy/x86_64-pc-gnu-linux/ or similar),
which is pretty redundant, but means that the versions don't compete
for the same file names in arch-independent hierarchies.

For more information about how this is managed, ask Mike Sperber about
--with-prefix=no.  I don't know the details.

Re: Version naming

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Oct 15, 2014, at 10:47 PM, Stefan Monnier wrote:

>The real underlying cause is dpkg's inability to handle simultaneous
>installs of different versions of the same package.  As a result, you
>get more work, as you point out, and I can't easily keep around all the
>versions I'd like to keep.

It depends.  We can install multiple different versions of Python
simultaneously, including both Python 2[*] and Python 3, but it took a lot of
work both in upstream and in Debian by the Python maintainers to make that
happen.

Cheers,
-Barry

[*] Although we only care about Python 2.7 now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Version naming

[Rob Browning]

Barry Warsaw <barry@python.org> writes:

> It depends.  We can install multiple different versions of Python
> simultaneously, including both Python 2[*] and Python 3, but it took a lot of
> work both in upstream and in Debian by the Python maintainers to make that
> happen.

I suspect we handle emacsXY in a roughly similar way -- but I don't
think either one is /opt style; I suspect both follow the FHS.

The info pages complicate things a bit since we have to have
/usr/share/info/emacs-XY.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Version naming

[Stefan Monnier]

>> The real underlying cause is dpkg's inability to handle simultaneous
>> installs of different versions of the same package.  As a result, you
>> get more work, as you point out, and I can't easily keep around all the
>> versions I'd like to keep.
> It depends.  We can install multiple different versions of Python
> simultaneously, including both Python 2[*] and Python 3, but it took a lot of
> work both in upstream and in Debian by the Python maintainers to make that
> happen.

But you only get to do that by lying to dpkg and pretending that python2
and python3 are just different packages rather than different versions
of the package.  So you need to know beforehand which sets of packages
people may want to keep together.

The packaging of Emacs does the same with distinct emacs19, emacs20,
emacs21, emacs22, emacs23, and emacs24 packages, each with its own set
of versions.  For those users who only want "emacs", it leads to
superfluous packages lying around.  For the maintainers, it leads to
extra work.  And for users like me, it still doesn't let me cleanly
install Emacs-24.1, Emacs-24.2, and Emacs-24.3 at the same time.


        Stefan

Re: Version naming

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

On Oct 16, 2014, at 04:01 PM, Stefan Monnier wrote:

>But you only get to do that by lying to dpkg and pretending that python2
>and python3 are just different packages rather than different versions
>of the package.  So you need to know beforehand which sets of packages
>people may want to keep together.

I'm not sure what you mean here, or whether Python's case is relevant to
Emacs, so I'll just mention the following and then re-lurk. :)

Each major Python version that Debian supports is a separate binary package,
e.g. python2.6, python2.7, python3.3, python3.4, etc. and that makes sense,
since each is an entirely different upstream release.  I don't see that as
"lying to dpkg"; for Python, it's true.

However, they are all co-installable, so you can have any combination of
whatever still-supported versions are in the archive.  The previous comment
about only caring about Python 2.7 is because all older versions are retired
upstream, and thus removed from Debian Jessie.

(Anything Python 3 older than 3.4 is currently in the same boat, but when
Python 3.5 is available, it's likely that both 3.4 and 3.5 will be supported
at the same time for a while.  No infrastructure changes will be needed to
enable that.)

Of course, "python" (i.e /usr/bin/python) and "python3" (/usr/bin/python3)
give you just one of those, whichever is the default version for Debian.
However, you can always also just run "python3.4" or "python3.5" or whatever.
I guess that's the analogy to "emacs" currently giving me 24.3.1 but being
able to run emacs23 if I wanted to... which I can. :)

The real trick to co-installability is that third party modules need to be
installable for all supported Pythons, and actually installed for all
installed Pythons.  Meaning, if package foo is available for 3.4, and then you
install Python 3.5, foo will magically also be available for 3.5 too.  Where
upstream got involved was redesigning the import system to support
co-installability of modules for multiple versions of Python (PEPs 3147 and
3149 for the interested Pythonista).  When Pythons earlier than 2.7 were still
around, Debian had to go jump through hoops (spelled "symlink farm") to make
that work, and it was a fragile hack.  Yet another reason to love Python 3. :)

It's also true that Debian has two different Python "stacks", one for Python 2
and another for Python 3.  That means if foo supports both, then you will have
a python-foo and a python3-foo binary package, but you will generally not have
a python3.4-foo and a python3.5-foo.  And in fact both binary packages are
usually created from the same upstream and Debian source package.  This makes
sense for Python because we do hope to some day remove Python 2, and in Ubuntu
demote Python 2 to universe.  There's also no need to install the Python 2
stack if you're just using Python 3.

Anyway, I'm off-topic for Emacs, so I'll stop here, except to add that Emacs
24.3 works really great for me on Debuntu.  Kudos to the maintainers.

/me waves to Rob.

Cheers,
-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Version naming

[Stephen J. Turnbull]

Stefan Monnier writes:

 > But you only get to do that by lying to dpkg and pretending that python2
 > and python3 are just different packages rather than different versions
 > of the package.

They are different packages, as different as, oh, Emacs and Guile. :)
It's possible to maintain sources that are compatible with both, but
their interpreters and standard libraries etc. are completely separate
now, and their dependencies are growing apart rapidly.

Your statement is true to a great extent among python2x packages, and
to some extent (more and more so over time) for python3x packages,
though.

 > And for users like me, it still doesn't let me cleanly install
 > Emacs-24.1, Emacs-24.2, and Emacs-24.3 at the same time.

I'm not clear on what you mean by "cleanly".  I suspect that in the
general case you need application bundles, with non-forward-compatible
dependencies installed in the bundle.  Of course when a version is
first released, you don't know when it will become non-forward-
compatible.

So I guess the solution would be to provide an option to statically
link any libraries that lack a strict backward compatibility promise.
But that has its problems too (although possibly not so much in your
application).

I suspect you are asking for the impossible.

Re: Version naming

[Stefan Monnier]

> I suspect you are asking for the impossible.

IIUC Nix/Guix has some kind of solution for this impossible problem.


        Stefan

Re: Version naming

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The packaging of Emacs does the same with distinct emacs19, emacs20,
> emacs21, emacs22, emacs23, and emacs24 packages, each with its own set
> of versions.  For those users who only want "emacs", it leads to
> superfluous packages lying around.  For the maintainers, it leads to
> extra work.  And for users like me, it still doesn't let me cleanly
> install Emacs-24.1, Emacs-24.2, and Emacs-24.3 at the same time.

At the cost of a lot of disk space, you can install each of those in a
separate chroot. I don't know if that qualifies as "easily" for you; I
got used to chroot when I was maintaining a couple Debian packages.

-- 
-- Stephe

Re: Version naming

[Stefan Monnier]

> At the cost of a lot of disk space, you can install each of those in a
> separate chroot. I don't know if that qualifies as "easily" for you;

No, it definitely doesn't qualify.  First, because the problem is to
solve it within the Debian package system whereas your solution works
around it.  Second because if you're willing to solve it outside the
package system, then there are simpler solutions that use up a lot less
disk space ;-)

Among the solutions that use up less disk space:
- don't install the .debs but just compile manually and "make install".
- patch the .debs so they all get a different name.

> I got used to chroot when I was maintaining a couple Debian packages.

chroot can be handy, indeed, but it comes with its own set of problems.


        Stefan

Re: Version naming

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> At the cost of a lot of disk space, you can install each of those in a
>> separate chroot. I don't know if that qualifies as "easily" for you;
>
> No, it definitely doesn't qualify.  First, because the problem is to
> solve it within the Debian package system whereas your solution works
> around it.  

Well, my point was you can use the Debian package system in each chroot,
and get different versions of the package installed.

I agree it would be nice to be able to do that in a single root, but I
suspect it is not possible in general, because there could be
conflicting requirements; you'd end up with full copies of /* for each
version anyway.

> - don't install the .debs but just compile manually and "make
> install".

This is certainly what I do, usually without the 'make install'.

-- 
-- Stephe

Re: Version naming

[Stefan Monnier]

> I agree it would be nice to be able to do that in a single root, but I
> suspect it is not possible in general, because there could be
> conflicting requirements; you'd end up with full copies of /* for each
> version anyway.

I can't see why.  I already have emacs19, emacs20, emacs21, emacs22,
emacs23, and emacs24 installed at the same time, so I can't see what new
problem would be introduced by refining this to the minor
version number.


        Stefan

Re: Version naming

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I agree it would be nice to be able to do that in a single root, but I
>> suspect it is not possible in general, because there could be
>> conflicting requirements; you'd end up with full copies of /* for each
>> version anyway.
>
> I can't see why.  I already have emacs19, emacs20, emacs21, emacs22,
> emacs23, and emacs24 installed at the same time, so I can't see what new
> problem would be introduced by refining this to the minor
> version number.

For specific packages with similar dependencies, that works.

But suppose emacs19 depended on gtk1, and emacs20 on gtk2, emacs21 on
gtk3, etc. And each gtkn had different, changing dependencies as well.

You'd end up with unique copies of the entire dependency tree for each
emacsn.

In practice, since the dependencies are more stable than that, the total
tree would be much smaller than the full copy for each that you get from
the chroot approach.

I suspect, as has been said here before, the main problem is the
maintainer effort required to make installing minor versions in parallel
possible; renaming files to include version numbers in every file
name/path for each release. dpkg doesn't do that for you.

If you tried to upgrade dpkg to do the file/path versioning automatically,
it would have to take a very conservative approach, leading the full
copy as above.

That might work, but I suspect there would be problems; for example, if
C headers have "#include foo<version>;"; dpkg could not possibly be
expected to handle that by editing the file. Any hardcoded version in a
build script or source file would fail.

-- 
-- Stephe

Re: Version naming

[Stefan Monnier]

> I suspect, as has been said here before, the main problem is the
> maintainer effort required to make installing minor versions in parallel
> possible; renaming files to include version numbers in every file
> name/path for each release. dpkg doesn't do that for you.

For Emacs, this is a non-issue, since Emacs already includes the release
string in pretty much all the file names (with very chosen exceptions,
such as "bin/emacs").


        Stefan

Re: Version naming

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> The info pages complicate things a bit since we have to have
> /usr/share/info/emacs-XY.

One other thing that would be handy (if it's not already possible) is an
easy way to generate and install info pages for multiple major releases
(at least) at the same time.

In Debian, as a hack, we just store all the pages under
.../share/info/emacs-N/, and then mangle the START-INFO-DIR-ENTRY to
refer to emacs-N/foo instead of foo. i.e.

  * Emacs: (emacs-24/emacs).               The extensible self-documenting text editor.

This works somewhat, but I seem to recall there were some issues with
either the standalone reader or Emacs (though perhaps they've been
fixed).

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Version naming

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 23 Oct 2014 20:08:15 -0500
> 
> One other thing that would be handy (if it's not already possible) is an
> easy way to generate and install info pages for multiple major releases
> (at least) at the same time.

That's not an Emacs problem.  This is a general problem with Texinfo:
it doesn't support such installation.  It's a long-standing missing
feature, so please take it up with the Texinfo developers, so that
perhaps in some not-so-distant future we might have a reliable
solution for it.

> In Debian, as a hack, we just store all the pages under
> .../share/info/emacs-N/, and then mangle the START-INFO-DIR-ENTRY to
> refer to emacs-N/foo instead of foo. i.e.
> 
>   * Emacs: (emacs-24/emacs).               The extensible self-documenting text editor.
> 
> This works somewhat, but I seem to recall there were some issues with
> either the standalone reader or Emacs (though perhaps they've been
> fixed).

Yes, this kludge is well known, but it doesn't work very well, as I'm
sure you know.

Again, this is a Texinfo problem.  Once Texinfo comes up with a
solution that the stand-alone Info reader implements, I'm sure Emacs
will follow suit in no time.

Re: Version naming

[Ulrich Mueller]

>>>>> On Thu, 23 Oct 2014, Rob Browning wrote:

>> The info pages complicate things a bit since we have to have
>> /usr/share/info/emacs-XY.

> One other thing that would be handy (if it's not already possible) is an
> easy way to generate and install info pages for multiple major releases
> (at least) at the same time.

> In Debian, as a hack, we just store all the pages under
> .../share/info/emacs-N/, and then mangle the START-INFO-DIR-ENTRY to
> refer to emacs-N/foo instead of foo. i.e.

>   * Emacs: (emacs-24/emacs).               The extensible self-documenting text editor.

> This works somewhat, but I seem to recall there were some issues with
> either the standalone reader or Emacs (though perhaps they've been
> fixed).

Similar workaround in Gentoo: We install the Info pages in
/usr/share/info/emacs-N/ (with e.g., N = 24) and add the directory
corresponding to the currently active Emacs version to the INFOPATH
environment variable. As an additional hack, we add the directory also
to Info-directory-list in Emacs' site initialisation (and make sure
that it occurs first in the list).

This way, each Emacs will see the right version of its Info pages.
The standalone reader will see the version that was added to INFOPATH.

Ulrich