ginga
ginga copied to clipboard
ejeschke
Release 4.0
Issue for resolving items for Release 4.0, a major release update.
ToDo list:
- [x] resolve #898
- [x] resolve #804
- [x] merge #973
- [x] merge #984
- [x] merge #995
- [x] merge #996
- [x] merge #1013
- [ ] merge #1017
@pllim, I am thinking of creating a 4.0 branch, that would contain any PRs destined for the next major release. This branch would be periodically rebased on top of the current main, allowing us to test it and optionally deploy it early as a alpha/beta release. After the release of 3.4 we would rebase one last time and merge that branch into main.
You have the benefit of knowing the astropy development process; does this seem reasonable?
astropy uses backports (branching of released version) so I am not familiar with the forwardport model. Are you trying to do git flow? I am not familiar with that either, sorry.
Or do you mean you want to branch out both v3.x and v4.x, and then backport PRs from main into both, accordingly? It is possible but quite a hassle to maintain. I have headache trying to backport just into one release branch on astropy. A lot of conflicts to resolve as timeline progresses and branch deviates more from main.
Well the main branch is essentially a dev line for 3.4 at this point, so no need to branch that. What I'm thinking is to have two more releases this year: a 3.4 release in the summer and then a major 4.0 release in the fall. I'm just trying to think of a way to be able to test the 4.0 release earlier so that we can spot any blockers. Of course, it's possible for me to simply make my own private branch to do this, but I'm thinking it would be useful if it was shared so that you and any interested others could test against it as well, if desired.
So maybe the 4.0 branch would simply exist as a kind of alpha of the 4.0 release. It would never get merged, and would be deleted after the release. But we would occasionally branch main and merge in the PRs that are waiting for 4.0 and then push this to a testing branch. This would allow us to test an alpha of 4.0 to see if there are any issues that need to be addressed in the PRs that are waiting. This might work easier if we just delete the branch before pushing every time so that there is no need to rebase anything.
Thinking about how this would practically be handled, I'd probably just push that branch as a PR that we would mark as a testing PR and agree would never be merged.
I could just keep force-pushing the branch to that same PR every time I made a new testing version.