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

Reply via email to