Are Developmental releases a type of pre-release?

Packaging
1

This has come up in a couple of discussions recently, but if one were to look at the spec for versions and read pre-releases and dev-releases:

Pre-releases

Some projects use an “alpha, beta, release candidate” pre-release cycle to support testing by their users prior to a final release.

If used as part of a project’s development cycle, these pre-releases are indicated by including a pre-release segment in the version identifier:

X.YaN # Alpha release
X.YbN # Beta release
X.YrcN # Release Candidate
X.Y # Final release

A version identifier that consists solely of a release segment and a pre-release segment is termed a “pre-release”.

The pre-release segment consists of an alphabetical identifier for the pre-release phase, along with a non-negative integer value. Pre-releases for a given release are ordered first by phase (alpha, beta, release candidate) and then by the numerical component within that phase.

Installation tools MAY accept both c and rc releases for a common release segment in order to handle some existing legacy distributions.

Installation tools SHOULD interpret c versions as being equivalent to rc versions (that is, c1 indicates the same version as rc1).

Build tools, publication tools and index servers SHOULD disallow the creation of both rc and c releases for a common release segment.

Developmental releases

Some projects make regular developmental releases, and system packagers (especially for Linux distributions) may wish to create early releases directly from source control which do not conflict with later project releases.

If used as part of a project’s development cycle, these developmental releases are indicated by including a developmental release segment in the version identifier:

X.Y.devN # Developmental release

A version identifier that includes a developmental release segment is termed a “developmental release”.

The developmental release segment consists of the string .dev, followed by a non-negative integer value. Developmental releases are ordered by their numerical component, immediately before the corresponding release (and before any pre-releases with the same release segment), and following any previous release (including any post-releases).

Developmental releases are also permitted for pre-releases and post-releases:

X.YaN.devM # Developmental release of an alpha release
X.YbN.devM # Developmental release of a beta release
X.YrcN.devM # Developmental release of a release candidate
X.Y.postN.devM # Developmental release of a post-release

Going just by that text I think it’s fairly clear that developmental releases are, by themselves, not a form of pre-release.

However, other parts of the spec, such as “Handling of pre-releases” state otherwise:

Pre-releases of any kind, including developmental releases

And that’s how it’s implemented in packaging:

>>> from packaging.version import Version
>>> Version("1.0dev0").is_prerelease
True

I propose the spec should be clarified to say Developmental releases are a type of pre-release.

Otherwise other parts of the spec, and packaging, should be updated as they are incorrect in their use of the term “pre-release”.

2

I was going to point out that “1.0dev0” isn’t compliant with the spec (it should be separated, 1.0.dev0) but it looks like that version is still considered is_prerelease so what do I know.

edit: I would also say that the quote “pre-releases of any kind, including dev releases” can be interpreted to be specifically referring to dev releases of pre-releases, not implying that all dev releases are pre-releases. So that’s not inconsistent with the previous definition.

3

I was going to point out that “1.0dev0” isn’t compliant with the spec (it should be separated, 1.0.dev0)

Version specifiers have a very long normalization section, the relevant section here is Development release separators, which among other things allows omitting the separator.

I would also say that the quote “pre-releases of any kind, including dev releases” can be interpreted to be specifically referring to dev releases of pre-releases, not implying that all dev releases are pre-releases. So that’s not inconsistent with the previous definition.

Yes, but that interpretation would be inconsistent with every tool that has implemented the section “Handling of pre-releases”, and if it was agreed that did not mean dev-releases of final releases, but only dev-releases of pre-releases, then every tool would need to make a breaking change (or at least packaging, pip, pdm, poetry, and uv would).

It would also require an additional section to the spec titled “Handling of developmental releases”, as it would be unclear if dev releases should imply dev or pre releases.

2 Likes