Allow option for developmental releases defined in PEP 440. #9
Conversation
|
Any thoughts on pulling this request in? |
|
Really sorry. I'm trying to schedule time so I can get around to all of my currently-neglected projects. |
|
@habnabit I would also need this feature, can I somehow support? |
| suffix references a corresponding future release, so vcversioner will | ||
| assume that the future release is a single version higher than the | ||
| current commit. For example, if the current commit is one revision past | ||
| the ``2.0.1`` tag, the computed version will be ``2.0.2dev1``. |
There was a problem hiding this comment.
This seems presumptive (and presumptively wrong I think).
The following release isn't necessarily a patch release. If one had to guess, I think guessing it'd be a minor release would be a better default, but even better IMHO would be a way to not guess somehow. I don't have any ideas there unfortunately though.
There was a problem hiding this comment.
Maybe changing this to instead take lambda current: next_version and having that by default be a callable that returns the next minor version would be a thing.
There was a problem hiding this comment.
Making that configurable would be fine to me. The reason it updates the last digit of any tag is so that it sorts properly if you ever tag ANY higher version.
For example let's say you're currently on release v1.3.4, and you do some work and make a commit. With this option enabled, you'll get v1.3.5dev1. If you then decide to tag v1.3.5 or v1.4.0 or v2.0.0, they'll all properly sort after the dev version.
Now, if the option chose to give you 1.4.0dev1 instead, and you decided to tag a v1.3.5 because it really was just a patch fix, the dev version will sort as "newer".
The neat benefit of updating the last number is that it works with alpha, beta, and RC builds too. For example, let's say you are preparing for a big v2.0.0 release and want to put some alpha builds out there. You tag a v2.0.0a1 build, send it out to some people to test, and get some feedback about things to fix. You fix the first bug, commit and build, and the dev option gives you a v2.0.0a2dev1 version. Make another change, commit and build, and you get v2.0.0a2dev2. Now you can tag a new alpha v2.0.0a2 and it'll sort correctly, or go ahead and tag v2.0.0, which will also sort correctly.
Overall, I would be happy with the "postX" functionality except that pip treats those versions as "real" releases compared to alpha, beta, rc, and dev "pre-releases", which you can avoid installing by not using the --pre flag.
There was a problem hiding this comment.
All of that said, I'd be more than happy to add the lambda and associated documentation if it would make it more likely to be merged in! 😃
There was a problem hiding this comment.
@Julian Any thoughts on this? I can add the lambda current: next_version if that feels required to move forward.
|
So sorry I haven't set aside time to review this yet. I'm going to schedule
some for tonight.
…On Tue, Feb 7, 2017 at 10:49 AM, Tyler Crumpton ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In vcversioner.py <#9>:
> @@ -73,6 +74,14 @@ def find_version(include_dev_version=True, root='%(pwd)s',
the version number will be ``1.0.post3``. This behavior can be disabled
by setting this parameter to ``False``.
+ :param use_dev_not_post: PEP 440 states that versions created during
+ development cycles should use the ``.dev`` suffix instead of ``.post.``
+ This suffix can be used by setting this parameter to ``True``. This
+ suffix references a corresponding future release, so vcversioner will
+ assume that the future release is a single version higher than the
+ current commit. For example, if the current commit is one revision past
+ the ``2.0.1`` tag, the computed version will be ``2.0.2dev1``.
@Julian <https://github.com/Julian> Any thoughts on this? I can add the lambda
current: next_version if that feels required to move forward.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABSsF3Cu46HDKiS7jsYmRJ45guq59h8ks5raLyjgaJpZM4JBvm8>
.
|
|
The idea is +1 from me I think, though I haven't read PEP 440 close enough to be sure, but it's @habnabit's opinion that matters :) (Sorry for the wait :/) |
|
Hey, just wanted to give a gentle ping 😄 This is still a feature that we use constantly and would love to see it in the official project! |
|
Hey there! Any new thoughts on pulling in something like this? |
Added 'no_subst_vcs_args' flag
|
Ack, sorry for the commit/rebuild noise here! I forgot that this PR was based off of tylercrumpton/vcversioner@master, so a change I was playing with got yanked in by accident. Should be reverted out now, and the PR can be squashed if we still want to pull the dev-version changes in. |
Fixes #8. I'm willing to change the name of the option or make any tweaks as necessary.