Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Infra: When and how to prepare the 2.10.x line?
See original GitHub issueSituation
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
Issue Analytics
- State:
- Created 4 years ago
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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? 😉
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.