-
-
Notifications
You must be signed in to change notification settings - Fork 282
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
Moving v3 development to main
#2308
Comments
I like this idea! But I'm far from a git pro, so perhaps I'm not the champion we need. |
|
Left to be determined. Open to opinions. |
For at least 6 months we're going to need parallel branches, so I don't think we can do a merge |
👍 - what we could do is merge current |
👍 sounds good, for anyone brave enough to try 😄 |
😄
runs cleanly cleanly at least. shrug
nods though I didn't check what the |
Right. Its not going to be possible to trace the "blame" for changes from v2 to v3 -- that's what we get for starting fresh 🤷 . But the history is there so the linear is technically maintained. I've created a few resources:
After #2330 goes in, we can do the reverse process and merge |
This sounds like it's going to be quite disruptive - maybe it's worth waiting until a point where there are less open PRs (when v3 comes out maybe?) to do this? |
I don't think it will be that bad. There are only a few active PRs against main at this point. We can manually change the base branch for those. And for the PRs that are pointing at |
I'm not 100% sure that GH will change the branch after #2341 is merged, as that's just a merge commit that doesn't signal to GH that we're renaming branches. Instead of #2341, we could delete the |
Change of the main branch also require a small number of setting changes to add branch protection etc. |
I seem to recall that if you delete a branch that is the base branch for a PR, they'll be immediately closed. You've only got 2 left that target |
Here's the behavior we should expect:
|
This does not describe the same scenario as @dstansby suggested above, which was to delete |
It seems like that will work - for some reason I can't put my finger on I think deleting So I'd say delete |
How will that interact with Is there an argument not to delete |
I'm realizing I have a fundamental aversion to deleting branches :)
Rebase would simply add the |
Rebase and merge would linearize the history; there are many splits and merges in the Don't let GitHub limitations over-complicate this for you; it's 3 lines on the command line:
and since you already have #2341 open, you already know that CI will pass. The PR will also be automatically marked as merged once GitHub sees you've done it yourself. |
I'm happy to run these commands. I agree they are functionally what we want. |
Over the past 9 months, we have been working hard on a major update to Zarr-Python (props to everyone who has been working hard on this, its really coming together nicely). This work has been developed on the
v3
branch. Now that we are in the last mile of the 3.0 release (#1777), I propose we transition this work to themain
branch. Along with this move, I also propose we create a support branch for 2.x so that we can continue to make bug-fix releases for at least the next 6 months.@zarr-developers/python-core-devs -- looking for feedback on the proposal and a champion to manage the git ops to make this happen.
support/2.x
)main
intov3
V3 main sync w/ merge #2335v3
intomain
The text was updated successfully, but these errors were encountered: