Tagging an alpha version of a package?

Has anyone ever tagged (and made a PR via METADATA) an alpha version of their package that is designed to allow people to test and install a major update easily, before it becomes an official version? If so, what was your process?

I don’t think that METADATA and Pkg2 support distinguishing between “prereleases” and “releases”. Presumably something like this might come with Pkg3.

All the time. It’s usually best to weave in the newer version while you deprecate old APIs. Usually the documentation becomes more and more focused on pushing people to the newer setup, until depwarns mean that we can take it out of the docs, and then depwarns are gone after another release.

According to SemVer2:

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

There are plenty of 0.x.y packages in METADATA.
They are all to be considered Alpha.
They don’t have to follow most of SemVer. In particular they are allowed to make breaking changes in patch and minor versions. Though I would personally suggest they do it in minor versions, like JuliaLang/julia does.

Sorry for the confusion; semver definitions weren’t exactly what I had in mind.

LightGraphs is “stable” at 0.7.3 right now. That is, it works, there are no breaking changes, major issues, etc.

We are in the middle of a pretty significant overhaul in preparation for Julia 0.6. This overhaul is currently in a test branch, but I’d like to make it easier for folks to test/use it before we make it official. That is, I’d like to tag a “LightGraphs 1.0-alpha” (we’re moving to 1.0 with this new code) and have people who rely on LG pound on it for a while.

Is this possible to do without messing up a bunch of stuff? What’s the process?

Just tell people to use master for the latest developments? Or some other branch?

Yeah, I guess Pkg.checkout() is the way to do this. Thanks.

You could also have the users Pkg.checkout("LightGraphs", "branchname") so that they can stay on your release candidate branch rather than master.