How to do a beta release on ELPA?

How to do a beta release on ELPA?

[Tassilo Horn]

Hi all,

we've worked hard lately to make GNU AUCTeX use lexical-binding.  That
was quite some work with certain deeper and also some incompatible
changes which could bite some users, especially those who have written
custom style files.  I think it's all for the better but there are
chances that some users might need to do some manual tweaking to their
customization and styles when upgrading.

We just made a last tarball release 12.3 and ELPA release 12.3.1 without
lexical-binding, and now our master branch contains the relevant
lexical-binding changes.

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?

I currently see only these two options:

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

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.

With option 1), I eschew the amount of maintenance required.  And what
should packages do that depend on auctex?  Now they need to depend on
auctex or auctex-beta.  Oh, and we'd need to declare both of them as
being incompatible to each other.  And the beta package should just be a
very temporary thingy, nothing that's still available and falsely
attracting users in a year from now...

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

Are there any other (preferably better!) options?

Bye,
Tassilo

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

Re: How to do a beta release on ELPA?

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> 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.

Ok, I guessed so.

> 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.

You gotta have plans.

>> 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.

Yes, we'll release it as GNU AUCTeX 13.0.0 on ELPA and when things have
stabilized, we'll do a 13.1 tarball release.  So the current version 12
is the last one of the pre-lexical-binding era.

>> 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.

Yes, I guess such a first use message pointing to the docs where we
describe exactly what has changed and how to migrate would be a good
solution.

>> 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.

Nah, I'm happy those are all gone.  :-)

> 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.

Yes, that's definitely what we are planning to do and the reason it'll
be on ELPA first.

> 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, ...

That's creative indeed!

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

Please stop it! ;-)

Thanks,
  Tassilo

Re: How to do a beta release on ELPA?

[Stefan Monnier]

>> 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.
> You gotta have plans.

I'm so glad you're volunteering, really.
I know many people will really appreciate it,


        Stefan ;-)