Open tylercrumpton opened 8 years ago
I actually used to have it to .dev
instead of .post
, but the problem is
that 1.0.dev1
< 1.0
< 1.0.post1
. You want commits made after a
release to order after the release, not before the release.
Indeed. The way I have things setup right now is that if you have something tagged "1.0" and commit once after that, vcversioner returns "1.1.dev1". It even works for situations like alpha builds where one commit after "1.0.2a1" becomes "1.0.2a2.dev1".
This really helped with our CI builds stomping all over actual "releases", by taking advantage of that --pre
tag.
The biggest drawback I see is that it enforces a PEP-440-ish version tag to begin with, if the option is enabled.
PEP 440 describes a
.devX
suffix that describes developmental releases leading up to a full release.In my projects, I'd like to use this nomenclature, since pip will choose not to install
.dev
releases unless the--pre
option is included. We push development versions on CI builds, which vcversioner currently tags with a.postX
suffix. These version do get installed without the--pre
tag which can be undesirable for development builds. PEP 440 even states that "the use of post-releases to publish maintenance releases containing actual bug fixes is strongly discouraged. In general, it is better to use a longer release number and increment the final component for each maintenance release."I have a fork of vcversioner that contains an option
use_dev_not_post
, and am looking for feedback on whether such a change would be considered for inclusion into the upstream project. I'm not attached to the option name either, if there is a better one available.