-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to CalVer and set a release cadence #5324
Conversation
+1 A very minor question - given that we're currently at 10.0, switching to 18.0 isn't visually very different. Would there be any value in going to 2018.0, 2018.1, ... instead? One other thing, I'd quite like to formally document that we must ensure that master is in a releasable state at all times, and that we explicitly don't follow any "only break things in major releases" policy (if we're breaking a documented behaviour, we will deprecate for a minimum of 1 release, more at our discretion, and if something's not documented, then all bets are off). But I'll produce a follow-up PR adding that to the docs, so it doesn't need to go in here. (We might also want to think about how the ReadTheDocs builds are named - "latest" and "stable" don't really make sense with CalVer. I don't know what options RTD offer, but again I'll look into that separately). |
@pfmoore I don't have a strong preference for I don't think there are any options besides |
I'm happy to stick with what everyone else is doing, tbh. Yeah, latest as "in master, what's coming in the next release" and stable as "the current release" seems fine to me. I think I was just confusing myself thinking about semver major/minor distinctions :-) |
This looks good to me -- other than the specifics of our deprecation policies which @pfmoore will be adding in a follow up PR. |
I've gone ahead and taken the liberty of updating our next milestone to be 18.0 and set a due date of 2nd July (it's the first Monday) for it. Feel free to call out if that doesn't seem right. :) |
Added deprecation policy and some other bits in #5328 as noted above |
At least I am glad that you didn't pick the YYYY version as it saves me a lot of keystrokes.... on the other hand it could have being much much worse, like adopting a full ISO-8601 versioning ;) Considering pip popularity, keeping it two digits saved few trees, avoiding extra energy consumption caused by the longer strings. 🌳 |
Why was this change made? What's wrong with semver? (I'm not trying to start a debate, I just haven't found any reasoning for this change anywhere.) Are the discussions that led to this change available anywhere for users to read? |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This switches us over to using a CalVer based version string as well as setting a 3 month release cadence.
The version strings will be
YY.N
, whereYY
is the two digit year, andN
is the serial number of the release within that year. Given our release cadence, that means that (pretending we had used this scheme all along) the versions for 2018 would look like:These months were chosen largely to try and avoid the major holidays in the Nov/Dec months. The documented policy is also that if there are no changes made to the
master
branch that need to be released, that month is simply skipped and the next release will be in the release month (so if nothing is to be released on April, then the next release will be in July).If we need to make any bug fixes to an already released version, then we would add a bug fix version number, like
18.0.1
,18.0.2
, etc.Since we're starting part way through the year, our first release with this scheme would be in July, and would be
18.0
.This pull request also adds a new type of news file fragments for process changes. I doubt we'll use them very much but it will let us call out process changes at the very top of our news file. Just naming a file
<whatever>.process
will let you do that. Since these generally won't have issue numbers, issue numbers will be hidden for them, so you can name them whatever you want (recommend a short, human recognizable string).Thoughts @pypa/pip-committers ?