My understanding is that since Pkg uses SemVer, pre-release versions like 2.0.0-rc.1 and similarly alpha and beta would be technically allowed for package versions.
What I would like to avoid is unsuspecting users upgraded from 1.4.0 to 2.0.0-rc.1 next time they Pkg.update(). Are there protections against this, or this is something one should avoid at this point by not releasing pre-release versions? My reading of Pkg.UpgradeLevel is that patch versions are nothing special and so the above update would just happen.
I guess one answer is: don’t register pre-release versions. Beyond that I guess we’d need a way for users to opt into getting pre-releases. You can always ask users to explicitly install pre-releases for testing.
because semver explicitly allows pre-release versions.
I understand that for a specific package, one can always install a branch or a tagged commit, so users can try out pre-release versions. But for a suite of packages, it would be easier to pre-release all of the dependencies, too.
So, just to recap, is the current viable solution to make an announcement like this?
Package Foo is ready nearing a new, major release, with breaking API changes and tons of improvements. If you want to test it before it is released, do
pkg> add Bar#master Foo#master
to install all dependencies correctly.
and not worry about pre-release tags since they go through the registry, so would have to be pulled manually?
To clarify: git allows you to tag things, regardless of whether it’s registered or not. You can also make a release on GitHub regardless of whether it is registered or not. The registration machinery doesn’t currently allow you to register pre-release versions, but it potentially could if we decide it’s a good idea. Have you tried tagging a prerelease and then using #1.2.4-alpha in place of the branch name? That might already “just work”.
Some coworkers and I were having a discussion about this very same topic just last week, so this question is timely. The simple git tag and then add MyPackage#1.2.4-alpha should work fine for a single standalone package.
But if MyPackage version 1.2.4-alpha depends on a pre-release of MySupportPackage (say, 0.8-alpha), or possibly an even larger set of pre-releases, then users would need to do
similar to what @Tamas_Papp mentioned above. This is a fine workaround to expect testers of pre-releases, but it would be awesome if Registrator and Pkg could handle pre-releases.
For the people that tend to work on Pkg, there are some more pressing issues to work on so this would likely need to be contributed by someone who has a strong desire for it.
Given that the potential early adopters of beta versions of packages are probably power users, I think that simply asking them to track #master of various packages is fine.
An API for this in Pkg would probably be equally or more complicated (does the user want to track pre-releases of all packages? if not, then which? yet another config, etc).
I was just asking for clarification, and now I understand things better. Thanks for all the answers.
There would have to be some kind of rule to avoid complexity. For example, “avoid pre-releases unless they are the only way to satisfy version constraints”. So in the examples above, you would never install any pre-releases unless
the user specifically added (directly or indirectly) package at a pre-release OR
some added or installed package requires a dependency at a pre-release version
I don’t think that’s too complex to wrap our heads around and would ease the “please test my package before I release it so I don’t break your stuff” problem.
Thanks @kristoffer.carlsson for outlining what changes would be needed to make this happen – I totally understand about developer priorities. Perhaps one of us will take a look at these needed changes and see if it’s something we can take a bite out of.
This is easy to automate if MyPackage uses test/Manifest.toml. The idea is that, if your direct dependency needs a pre-release version of the indirect dependencies, your direct dependency already must have the indirect dependencies with appropriate versions in its test/Manifest.toml. So, you can use MyPackage’s test/Manifest.toml to figure out that you need MySupportPackage#0.8-alpha. I’m doing something similar in Rogue.add.
For people finding this via search but wondering whether the information is stale, this is still accurate w.r.t. the level of support currently available.