Repository navigation
Infra: When and how to prepare the 2.10.x line? #183
Description
Situation
We've decided to freeze 2.10.x and no new features will be added to this version (except security and severe bugfixes). As we are going towards 3.0.0, master will contain the new version soon.
However, we still haven't thought about how to deal/manage both versions, old and new, so they can live peacefully together.
Proposed Solution
Probably we should open a maintenance branch for the 2.10.x line. The open questions are:
- When should we open the maintenance branch? Now or in the not so far future?
- How should we deal with upcoming 2.10.x versions?
Here is my idea that I would like to discuss with you:
- Make sure we have a clean, good state (should be already the case; but it doesn't hurt to look a bit deeper).
- Branch off from current master and create a
maint/2.10.0branch. We could also usestable/2.10.0. Any better name? 😉 - Change version in master to 3.0.0+alpha1 (just an example).
- Optionally indicate it in the README as "work in progress".
- Now we can start implementing code for 3.0.0 only.
After these steps, we have the new version in master and the old version in a maintenance branch. If and how we want to create a new release for the 2.10.x line, it's a matter of taste. One way to do it could be like this:
- Add the changes to the 2.10.0 maintenance branch.
- Raise version to 2.10.x.
- Tag the release.
- Publish the 2.10.x release.
It could be helpful to protect the maintenance branch like we did with master.
Anything else we need to cover? Comments? 😉
Update: Changed 2.9.x -> 2.10.0
Activity
s-celles commentedon Nov 6, 2019
I would let Python 2.7 die before
https://pythonclock.org/
2 months is not so long...
ppkt commentedon Nov 12, 2019
I think we could create this branch right now and start adding things for Py3.5+ only but it's only my opinion :)
tomschr commentedon Nov 13, 2019
@ppkt
Yes, I would have no problem to create a maintenance branch release for the 2.9.x series and adding new feature in the master branch (which would be the upcoming 3.0.0 release). I would love to start for the next major release. 😉
Of course, there are other ways to do it, like creating a dedicated 3.0.0-pre release branch, adding stuff there and then merge it to master when it's "ready".
Personally, I would prefer the first method (create a 2.9.x maintenance branch, master will be the upcoming 3.0.0 release). I think, it makes it a little bit easier.
tomschr commentedon Nov 13, 2019
Currently, we have a problem with Travis. For some reason, it doesn't finish its task and blocks our pull request(s). 😞 I'm not sure how to fix it...
ppkt commentedon Nov 13, 2019
@tomschr agree, I think separate branches for 2.9.x and 3.0.x would be great (so we could consider master as "stable" branch).
tomschr commentedon Nov 13, 2019
@ppkt Whatever works is fine for me. 😉 Let's see what @scls19fr has to say about that.
What would you prefer? Would you wait til January (as indicated in some other comment)? Or can we start right away? 😉
s-celles commentedon Nov 13, 2019
Submitting PR is always opened and discussion can occur on these PR.
We will see in January for merging them to master.
Maybe we should have a tag WIP (and/or Release 3.x.y) to just remember not to merge them.
I don't think we have enough human ressources for managing several branches (even if here several means 2 😄 )
In January we will create a 2.9.x branch before merging 3.x features to master.
So our 3.x.y development will be in master and we will have a 2.9.x branch if we need to go back (hoping that we won't need to do it)
tomschr commentedon Nov 13, 2019
That would be one way. Another way would be to open PRs as "Draft" . If you do that, merging is disabled unless you change "Draft" to "Ready for review".
s-celles commentedon Nov 13, 2019
I never used previously PR as Draft but it seems to be a good idea as it will be a place to have discussion about changes we expect to be merged for 3.x.y.
tomschr commentedon Jan 26, 2020
@scls19fr, @ppkt any new ideas how to proceed? Should we create a 2.9.1 release before we switch to 3.0.0?
For the major 3 release, I've created the release 3 project. Would it make sense to create something similar for the 2.9.1 release?
tomschr commentedon Apr 19, 2020
As we are preparing a 2.10.0 in #237 soon, this issue is related to it.
@python-semver/reviewers
Once 2.10.0 is released, I would suggest to work on the semver3 after. IMHO, that gives us the chance to remove all the old stuff of Python2 and focus on one code base.
Any concerns or objections about this idea? 😉
[-]Infra: When and how to prepare the 2.9.x line?[/-][+]Infra: When and how to prepare the 2.10.x line?[/+]tomschr commentedon May 5, 2020
I guess, this is solved by #246