search

ejeschke / ginga

The Ginga astronomical FITS file viewer
BSD 3-Clause "New" or "Revised" License
121 stars 77 forks source link

Release 4.0 #993

Closed ejeschke closed 1 year ago

ejeschke commented 2 years ago

Issue for resolving items for Release 4.0, a major release update.

ToDo list:

ejeschke commented 2 years ago

@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?

pllim commented 2 years ago

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.

pllim commented 2 years ago

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.

ejeschke commented 2 years ago

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.

ejeschke commented 2 years ago

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.

pllim commented 2 years ago

Re: as PR -- That might just work!

ejeschke commented 2 years ago

I could just keep force-pushing the branch to that same PR every time I made a new testing version.

ejeschke commented 2 years ago

See #994

ejeschke commented 1 year ago

Released!

pllim commented 1 year ago

Congrats!