Mosè Giordano <m...@gnu.org> writes: >> So doing another release anytime soon where the compat issues Ikumi >> found are fixed would be a good thing. Maybe an even better plan was >> to release 11.91 and 12.0 identically in parallel where 11.91 would >> be the last XEmacs (and Emacs 21/22/23?) compatible release and 12.0 >> the normal (recent Emacsen) release and to create an compat branch. >> Then we could have 11.91.x releases with just compat fixes for >> XEmacs/old Emacsen but no new features, and with version 12+ we could >> start caring about compatibility only for the last few Emacs >> releases. > > Do you mean that the branch would be for fixes only, so that in master > we can completely remove hundreds of lines of compatibility code? If > so, I'm all for this option.
Yes, exactly. >> I'm also thinking about maybe closing down our own git repository and >> move over to the emacs-elpa repository and do only ELPA releases (after >> all, you can do a system-wide installation of an ELPA package which is >> the main cause for the standalone release). Right now, the situation is >> not overly problematic but there were times where Stefan Monnier fixed >> tons of (mostly byte compilation) issues in auctex on emacs-elpa >> (thanks!) and I really had no joy in cherry-picking those changes to our >> own repository given that in auctex.git several files are generated >> during compilation but are checked in in emacs-elpa. > > I'm not completely convinced by this (but I didn't have to wrestle > with conflicting merges ;-). What would be other advantages? I think no conflicting merges/cherry-picks and a simpler (aka completely automated) ELPA release procedure are probably the only benefits. Bye, Tassilo _______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel