Lars Ingebrigtsen <la...@gnus.org> writes: > John Wiegley <jwieg...@gmail.com> writes: > >> We're moving toward a future where Emacs.git will represent "core >> Emacs", and only contain what core needs (plus a few historical bits, >> I'm sure). There should be no argument for keeping a project in core >> just to gain auxiliary benefits. > > I'm massively unenthusiastic about this future. Things in ELPA has to > be backwards-and-forwards compatible with a wide Emacs version range,
no, they don't. That is one possible policy, but each package decides for itself whether to follow it. You can have ;; package-requires: ((emacs "25.2")) if you want. If you want to maintain two versions, one for older emacs, one for newer, you'll need two different package names, similar to gtk2, gtk3. It does appear we need a "next release" branch in ELPA git similar to "master" in emacs git, so the released ELPA package is still available, but those working on emacs master can access the leading edge ELPA packages. > Emacs doesn't seem to have a massive surfeit of developers, so I wonder > where this plan comes from. Several developers prefer the decoupled development cycle of ELPA packages. It is primarily up to the package developers whether a package is in core or not, at least until it is clear that there is no advantage to being in core. -- -- Stephe
