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 …

[image] Tamas_Papp: 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. Actually no. Version identifiers are only given as x.y.z and the resolver and the registry only understands …

Is registrator/tag bot smart about pre-releases / releases? It would be great to have the functionality to opt into early releases.

Then perhaps I misunderstood the docs : the Julia package manager respects semantic versioning (semver) 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. …

You’re allowed to tag pre-release versions, you just can’t register them currently.

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 …

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 …

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 MySupportPac…

For this to happen the following would need to be done: Fixup the resolver to handle it. https://github.com/JuliaLang/Pkg.jl/blob/89603411622bc725f9f4b8f4fc94b0ac8772982d/src/resolve/VersionWeights.jl#L7-L13 etc. Fixup VersionRange in Pkg to handle it. Fixup Registrator.jl to handle it. For the…

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…

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 versions of packages

Internals & Design

MilesCranmer June 16, 2025, 3:14pm 22

Thanks Stefan; here is the new thread by the way: Can we have pre-release versions in the registry? (v2)

Topic		Replies	Views
Can we have pre-release versions in the registry? (v2) General Usage question , registry	31	827	June 16, 2025
Tagging an alpha version of a package? Internals & Design	7	884	March 22, 2017
Encouraging 1.x versions for registered packages? Package Management	74	2542	April 23, 2023
Getting to 1.0 -- How can we get packages to "make that tag"? Community	17	1435	April 20, 2021
New automerge requirement: Release notes required for breaking package releases Package Announcements general-registry , registryci	50	1811	January 2, 2025

Pre-release versions of packages

Related topics