Edward John Steere writes: > - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then > released; CEDET is at <some-hash-from-master-on-git> > - we update a registry somewhere indicating that Emacs 22.0 works with > <some-hash-from-master-on-git> and 22.1 works with > <some-hash-from-master-on-git> > - When we make updates to CEDET we mark 22.1 as working with > <some-new-hash-from-master-on-git> but we don't change that reference > for 22.0 (or any older versions) > - When someone complains that there's a bug in CEDET for 22.0 we > indicate that it's no longer supported and that they should update > Emacs to receive updates > > This process would almost be the same as what you get just by bundling > CEDET with Emacs except that: > > - You can get the latest CEDET *if* you have the latest Emacs
No. We have two branches: emacs-25 and master. The CEDET from master will usually not work on any 25.x version. > - The version of CEDET for any particular version of Emacs is as far as > CEDET got before the next release of Emacs came out > > If this is what you were thinking of then please could you elaborate on > what ended up being the problem which added more work. First off, CEDET is currently *not* a package, although that notion gets thrown around a lot. It is scattered across the Emacs code base: lisp/cedet, admin/grammars, etc/srecode, documentation, and test suite. All this needs to be packaged in a way so that it can be integrated into Emacs during a normal checkout. It needs to build and test in such a normal checkout, but also separately when installed from ELPA, including grammar compilation. And you need this twice: one for emacs-25, one for master, with the possiblity to merge between the two. Then there's this "registry". No one has said how that should work. "Submodules/Subtrees" are *not* a sufficient answer, they are just tools. People will need to say how the *workflow* should be, including such things like merges from stable, ChangeLog generation, AUTHORS, NEWS, creating release tarballs, and so on. Once someone has written this down *in detail*, we can discuss again if this indeed will make things simpler and reduce our workload. > I feel like there are aspects of CEDET which are still under > development. I hope so. >> Well, we cannot really discuss this since there's no real plan how this >> all should work. I can only speak from experience. > > We can still put ideas forward though. Haven't come up with anything > myself yet though. Yes, you can, but it has a cost. Once again, the CEDET merge is stalled, and we spend our time writing mails. I find this situation incredibly frustrating. >> How does CEDET, Gnus and Org affect the rest of Emacs? They strongly >> depend on Emacs "core" (whatever exactly that is), not the other way >> round. > > I believe that one of the intentions of the move is to enforce this so > we can't build bad dependencies -- am I wrong? I think other modes should use Semantic. > Perhaps I'm wrong, but to my mind the package approach would afford us > with more testing before we get to the point of another release of > Emacs. If you develop on Emacs 'master', you can use all the new features (like threading and FFI), but you loose testers on 25.x. A package won't change that. -David
