Re: Sync up the org in emacs master to org maint branch?

[Eli Zaretskii <eliz@gnu.org>]

> From: Edward John Steere <edward.steere@gmail.com>
> Date: Sun, 05 Feb 2017 11:03:31 +0200
> Cc: Bastien Guerry <bzg@gnu.org>, Emacs developers <emacs-devel@gnu.org>,
> 	Phillip Lord <phillip.lord@russet.org.uk>,
> 	emacs-org list <emacs-orgmode@gnu.org>,
> 	Kaushal Modi <kaushal.modi@gmail.com>
> 
> > It's not like packages communicate with Emacs over a well
> > defined RESTful interface. In other words: CEDET and Gnus are not
> > loosely coupled, quite the opposite: they are extremely dependend on
> > many obscure Emacs internals (not sure about Org).
> 
> Shouldn't we be trying to avoid this situation?  It's sure to come back
> and bite us in the future.  If we continue to develop a package
> (wherever it ends up being developed) which is so tightly coupled that
> any kind of re factoring in core becomes a nightmare, because we have to
> consider the umpteen ways in which it'll break the package, then surely
> that's a bad methodology to continue?  (I'm not suggesting that we
> rewrite it to make it more loosely coupled, just that it seems like a
> bad idea to continue allowing this going forward.)

How would you go about not allowing this to go forward?  I don't
think I see any practical way to do that; do you?

IMO, this is up to the package developers: if they want to depend less
on the Emacs internals, and thus be more loosely coupled with a
particular Emacs version, they will need to invest the extra effort
for that, e.g., by providing some compatibility shims.

IOW, this isn't an issue that can be solved once and for all by the
way we develop the core or the packages, or by the way we integrate
packages with core, the solution is on a different level.

> > As a consequence, we
> > and also the Gnus guys decided to not do separate releases anymore.  We
> > used to provide CEDET for different Emacs versions, and it was a *huge*
> > amount of work. I had a buildbot running with 7 or 8 Emacs versions to
> > run the test suite, and things broke pretty regularly.
> > Now you might say: fine, only release a package for current master. But
> > let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
> > Emacs 27 starts. Now there are changes happening in Emacs 27 that
> > require changes in CEDET, which make it incompatible with Emacs 26. So
> > you have to create two packages: one for 26, one for 27? Not only is
> > this confusing, but it most definitely increases my workload.
> 
> I feel like this problem isn't intractable.  We can mark some state of
> CEDET as being stable under the various versions of Emacs (because it
> was at the time) and then only support the current release for the
> latest package.  This would most likely require changes to package to
> ensure that you get an appropriate version of the package when you
> download it.

IF (and its a big "if") package developers want to be able to target
more than the single Emacs version on a single branch of the Emacs
repo, then they will need to provide at least 3 branches:

  . "development" branch that tracks the Emacs master branch and
    introduces exciting new features
  . "bugfix" branch that tracks the Emacs release branch without
    adding any new features
  . "stable" branch that is compatible with the Emacs release branch,
    but also introduces some new features, the ones that don't need
    core developments available only on the Emacs master branch

I envision that some packages will want the above (or maybe even a
more elaborate scheme), because they can afford that, and because
their users expect that.  These are mostly those packages whose
developers welcome the move to put more of Emacs on ELPA.  Other
packages, and I guess CEDET is one of them, will not want to do this,
because it adds too much work to an already complicated and
time-consuming job.

IOW, once again the solution is not part of the way we develop the
core or integrate non-core packages, it's elsewhere.

Bottom line, I think people are bothered by aspects of the "move to
ELPA" process that are not supposed to be affected by that move in any
way.  They are aspects that need to be resolved on entirely different
levels, and the resolution is up to the package maintainers.  That
includes a possible decision of the developers that some package will
not move to ELPA; I don't think that if a package developers say they
want to stay in emacs.git, they will be told to get out regardless.