Request for a `release/latest` branch or tag

[bonachea]

This issue requests creation and maintenance of a git ref (branch or tag, don't really care which) that always points to the latest stable public release of Chapel. The existence of such a ref helps git users to checkout the latest stable release of Chapel, without needing to know the exact version number.

The main reason I want this is to enable adding a git branch alias to the Chapel Spack formula that explicitly requests fetching the current public release from git (e.g., spack install chapel@stable). We could implement such an alias by updating the alias in the Spack formula after each public release, but that's not ideal because the update might not reach some Spack users for months after the Chapel release. Also, maintaining the ref in git would be more helpful to more people (i.e., those not using Spack).

I have no strong opinion on the naming, but release/latest seems to match the current naming convention in the Chapel repo. Other common alternatives could include stable or simply latest.

This ref would need to be updated during the Chapel release process, either by merging the release to a long-lived branch, or by moving the tag. This need not happen on release day, in fact there might be some benefit in performing this update after code freeze but before the release is officially announced.

CC: @bradcray @arezaii

[bradcray]

This need not happen on release day, in fact there might be some benefit in performing this update after code freeze but before the release is officially announced.

Dan, on slack, I got the sense you were pretty in favor of this (having the tag point to the impending release tarball after code freeze). And from a developer/testing standpoint that makes sense, but it makes me wonder about:

• also supporting a tag that only points at the latest truly released release (for end-users to use)
• using a name other than latest (it's not yet the latest release) or 'stable' (it may not be stable if the testing relying on it shows a problem)

Would this help with spack users and developers, or muddy the waters in some way I'm not seeing.

Seems like the main downside is that now there are two new tags to maintain rather than one. And naming (release/dev?)

[bonachea]

@bradcray said:

Dan, on slack, I got the sense you were pretty in favor of this (having the tag point to the impending release tarball after code freeze).

Note this enhancement request is solely for a git ref, so there's no "release tarball" artifact here: it's basically just a pointer to a commit in git representing "stable" code (where "stable" has presumably received more vetting than the usual day-to-day tip of main). Of course it's true that GitHub can automatically package any commit as a tarball on demand, but the mechanisms I'm talking about (git checkout and spack install from a git source) don't even use that capability.

Now to your questions: the creation of such a git ref (with any reasonable update discipline) gets me the majority of the functionality I'm requesting. Users who want a specific release number can always ask for it by name; this ref instead serves the interests of users who just want "the latest and greatest stable code" but don't care enough to carefully track Chapel releases and update their build scripts. IOW the difference between a ref updated at code freeze (and possibly moved again on release day) versus a ref that is only moved on release days is vanishingly small for the majority of the use cases I envision.

That being said, one (minor) benefit I see to providing a ref updated at code freeze is that it makes it easier for "early adopters" to help (perhaps unwittingly) with the testing effort during the freeze period, and possibly report problems that could improve the documentation of the impending release. Now assuming the code in main stays relatively unchanged during the freeze period, such users could theoretically use main for this purpose, but doing this with main requires more active user involvement: e.g., it presupposes those users carefully track your release schedule in order to know which weeks of the year the code in main is considered "fully stable" and expected to be mostly production-ready. With the proposed ref, users can (for example) permanently point their automated CI at that ref and have a reasonable expectation of "production adjacent" quality 365 days of the year, where any regressions represent something that should immediately be reported.

Regarding naming the git ref:
Spack has established conventions for the following "infinity versions": (ordered by "freshness")

develop > main > master > head > trunk > stable

all of which are always considered newer than any numbered version. So for technical reasons the Spack-side version label we deploy in the chapel spackage should be one of master | head | trunk | stable (the main label already points to git ref chapel:main). However the git-side name for this new ref can be whatever makes the most sense for the Chapel project, because we control the Spack-label-to-git-ref mapping.

FWIW the git discipline we follow in GASNet has one git ref (master) that always points to exactly the latest actual release, and a second git ref (stable) that is additionally updated between releases whenever we feel the code has reached a "stable" point (and usually has passed at least a week of automated testing). These are both separate from day-to-day development (develop), and we provide Spack labels for all three git refs in the GASNet spackage (where we map the gasnet:stable git ref to the Spack main label, in order to maintain Spack's preferred freshness relationship above). To be clear, I'm not suggesting Chapel adopt GASNet's naming or update convention, just providing it as an example.

[lydia-duncan]

Noting for others' benefit that this idea came up last week when we were discussing how to handle future large changes in general (I think Shreyas suggested it). I'll try to loop the concepts together more solidly and keep this issue up to date where reasonable