Re: Cutoff date for adding ruby-ts-mode?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 30 Dec 2022 23:42:50 +0200
> Cc: emacs-devel@gnu.org, pedz@easesoftware.com, monnier@IRO.UMontreal.CA
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> Alternatively, we break from the common scheme and put the modes in
> >> separate files, one depending on the other. Then they'll have to be
> >> separate GNU ELPA packages (I think), and we'll need to synchronously
> >> bump version and required-version in them every time when making
> >> interrelated changes in the future.
> > 
> > I'd prefer this alternative for now (modulo the separate ELPA packages
> > part, which I leave for you to decide: they could also be a single
> > package from my POV).  If nothing else, having separate files is
> > similar to what at least some other *-ts-mode's do.  When we revisit
> > these issues in the future, we'll be able to make the decisions about
> > all of them.
> 
> Okay.
> 
> I wonder what's going to happen if we release Emacs 29 with ruby-mode 
> and ruby-ts-mode in separate files, and then later add a package called 
> 'ruby' to ELPA with ruby.el containing both modes.

The ELPA package could also include 2 files, one for each mode.

> Will the autoloads file from an ELPA package always take priority over 
> the built-in autoloads? If yes, then we don't have to do anything now. 
> Hopefully that's not undefined behavior.
> 
> Alternatively, it would be possible to release two files as one ELPA 
> package, but it would seem to require a third file: one matching the 
> package name, ruby.el.

I'll leave this part of the issue to Stefan and others who know more
than I do about ELPA packaging.