Re: How to do a beta release on ELPA?

[Stefan Monnier]

> We've worked hard lately to make GNU AUCTeX use lexical-binding.

Cool!

> I don't think there are too many people running straight from our master
> branch, so I guess we should do a new ELPA release pretty soon to get
> more testing.  But is there a way to release a new ELPA version just for
> the adventurous?

Not really, no.
[ I mean, other than the obvious ones that involve more work on your
  side and/or on the side of those who want to install the new version.  ]

I'd like to create an alternative ELPA archive built from elpa.git but
using the latest code (kind of like the non-stable Melpa), but that's
been a TODO item for a while already and I've not even tried to get
started on it.

If such a thing existed you could just update the auctex code without
bumping the "Version:", and people following that "gnu-snapshot" archive
could then update the bleeding edge code.

> 1) Make a separate auctex-beta package which would just be the same as
>    the normal one except with a more recent release.

Sounds like a lot of trouble (including dealing with users which have
both packages installed, including an older `auctex-beta`, etc...)

> 2) Just do a normal ELPA release and if things break for some users tell
>    them how to pin auctex to version 12.3.1 for the time needed to fix
>    their issues.

That's what I'd recommend, yes.
I'd definitely give it a release version that sounds like "major release".
We're way past "2.0", so I'll let you find the next best choice.

> With option 1), I eschew the amount of maintenance required.  And what
> should packages do that depend on auctex?

Nothing.

> Now they need to depend on auctex or auctex-beta.

I wouldn't bother.

> Oh, and we'd need to declare both of them as being incompatible to each other.

There's no such mechanism.

> With option 2), I guess it could harm users who don't know how to reach
> out for help.

Maybe emit a warning during compilation or upon "first use", with an
appropriate description of the kind of problems that can happen.
Many users still won't read it, but it increases the chances that
they'll find someone who has.

> Are there any other (preferably better!) options?

Option 1: change the code so as not to introduce such backward
incompatibilities (e.g. Calendar ended keeping nasty dynamically scoped
vars like `date` and `month` in order to maximize compatibility with
existing code).  That can't be a 100% solution tho since there can
always be people who used non-documented vars via dynamic scoping.

Option 2: rely on the quick&easy release process: as soon as you
hear of one incompatibility, you immediately adjust the code (typically
to mark some var as dynscoped) and make a new minor release.

Option 3: (getting really creative here) make sure you new code makes no
other changes than switching to lexical-binding and then do temporary
release: release 12.3.2 with lexical-binding, then a week later release
12.3.3 without lexical-binding (i.e. reverting to the previous code) and
work on fixing the incompatibilities  found along the way, then try
again with the new&improved lexical-binding code, maybe leaving it for
a month instead of a week, ...

If you insist, I'm sure I can come up with an even more fun option 4.


        Stefan