Emacsair! Announcing two new experimental MELPA channels

">

Announcing two new experimental MELPA channels

MELPA is the original and independent Emacs Lisp package<br>archive.

A few days ago we have published two new MELPA channels, MELPA<br>Snapshots and MELPA Releases . For now these channels are<br>considered experimental and coexist with the traditional channels<br>MELPA (“regular” a.k.a. “unstable”) and MELPA Stable. Eventually<br>the snapshots channel is going to replace unstable, and releases<br>is going to replace stable. But don’t worry, if you are not ready<br>to update just yet; the new channels are still considered experimental<br>and the current thinking is that they won’t replace the traditional<br>channels for around another year.

Better version strings

After years in the making, MELPA is finally moving away from using<br>raw timestamps as version strings for development versions. While<br>the traditional unstable channel uses the version string format<br>YYYYMMDD.HHMM, the new snapshots channel uses<br>RELEASE.0.YYYYMMDD.COUNT.

RELEASE is the latest release, i.e., the version distributed on the<br>releases channel. YYYYMMDD is the committer date. Instead of<br>appending the time to the date, COUNT is used; the number of commits<br>since the latest release (i.e., RELEASE).

If no release information can be determined, then 0.0 is used as<br>RELEASE and COUNT is the number of commits since the initial<br>commit.

If no new commits since that release touch any files, that are<br>included in the package tarball, then the same release is distributed<br>on the snapshots channel as well; build from the same commit and<br>using the same RELEASE version string as on the releases channel.

That’s all wonderful, but just take me to the setup<br>instructions.

Versions going up

The main advantage of not using raw timestamps as version strings for<br>snapshots is, that a snapshot version will no longer be greater than<br>every release. That was a problem because it meant that any<br>snapshot seemingly satisfied the minimal dependency on even the very<br>latest release of a dependency. E.g., org-20040101.1234 is<br>considered greater than org-9.8.6, by version. The new snapshot<br>version strings do not have this issue:

1.2.3

What about the zero?

Instead of just ., we inject .0. in between the RELEASE and<br>DATE. We do that to allow package maintainers to add one version<br>string component when creating a new release, without throwing the<br>just mentioned improvement out of the window again. I.e., 2.0 .

Why DATE and COUNT?

Well, when that was first proposed, I mentioned that it has a definite<br>“designed by committee” feel to it, but I considered it a good<br>compromise and have come to actually like it.

I would have liked to use just COUNT because it is shorter and IMO<br>encodes more useful information than DATE.TIME. That being said,<br>both DATE and COUNT are useful information, and so it makes sense<br>to encode both in the version string.

Compatibility with other ELPA

A few weeks ago GNU-devel ELPA and NonGNU-devel ELPA also switched<br>to the RELEASE.0.DATE.COUNT format. Version string compatibility<br>between different ELPA is important, so I finally gave up on the<br>RELEASE.0.COUNT idea, and returned my focus to getting some sane<br>format across the finish line.

Sources of versioning truth

Until now, MELPA exclusively used git/mercurial tags to determine the<br>latest release and the commit corresponding to it, while (Non)GNU ELPA<br>exclusively use the Version or Package-Version library header.

Neither of these approaches is compatible with reality. Many<br>maintainers use only tags, while many other maintainers use only the<br>library header. To detect the latest release for most packages (that<br>actually do releases), a package archive has to consult both potential<br>sources of versioning truth.

For the new releases and snapshots channels we first consult the<br>tags, and iff there are no release tags, then we fall back to the<br>library header.

Because it considers both version information sources and also falls<br>back to using the 0.0 stand-in, if both version sources are void,<br>the releases channel features 6207 packages, compared to<br>stable’s 3400. (The reason why it doesn’t feature all 6240<br>packages, available from the unstable and snapshots channels,<br>is that the latest releases of these 33 packages are defective.)

Interlude I: How to create a release

I should expand on this in a separate post, but the gist is this:

Make sure you tag exactly the commit that bumps the Version<br>library header with the corresponding release tag. This way, and<br>only this way, the same commit will be considered to be release N,<br>regardless of whether some tool looks at the header or the tag, and<br>regardless of how it deals with conflicting information, if it<br>supports both sources.

If you forget to create (or push) a tag, that is not a huge issues;<br>once you notice, just tag the commit that bumped the header. If you<br>create a tag but forgot to bump the header, then that release is<br>broken and cannot be fixes, and you must create...