Moving v3 development to main

[jhamman]

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 the main 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.

• create support branch (support/2.x)
• merge main into v3 V3 main sync w/ merge #2335
• merge v3 into main

[d-v-b]

I like this idea! But I'm far from a git pro, so perhaps I'm not the champion we need.

[joshmoore]

• C: Kudos all around 🎉
• C: 👍 for the move
• C: 👍 for the 2.x branch
• Q: Are you proposing a rename or a merge? Or is that left to be determined?

[jhamman]

Q: Are you proposing a rename or a merge? Or is that left to be determined?

Left to be determined. Open to opinions.

[dstansby]

For at least 6 months we're going to need parallel branches, so I don't think we can do a merge

[jhamman]

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 main into v3 with a merge strategy of --ours. I believe that would help us maintain the history that has accumulated on main since we started work on v3.

[dstansby]

👍 sounds good, for anyone brave enough to try 😄

[joshmoore]

for anyone brave enough to try 😄

😄

    git clone [email protected]:zarr-developers/zarr-python
    cd zarr-python/
    git merge -s ours origin/main

runs cleanly cleanly at least. shrug

I believe that would help us maintain the history that has accumulated on main since we started work on v3.

nods though I didn't check what the follow-ablility of the files will be after the v2 module etc. are removed.

[jhamman]

nods though I didn't check what the follow-ablility of the files will be after the v2 module etc. are removed.

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:

• A new support branch (support/2.x) -- this was branched off main at eaf5d7a.
• A PR pulling the history from main into the v3 branch - V3<> main sync #2330

After #2330 goes in, we can do the reverse process and merge v3 -> main`. The final step will be to go through existing PRs and switch out the base.

[dstansby]

The final step will be to go through existing PRs and switch out the base.

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?

[jhamman]

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 v3, GitHub will automatically change the base branch after #2341 is merged.

[dstansby]

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 main branch, and rename v3 to main, which will definitely update the PRs to point to main? That might miss a benefit of merging v3 into main that I diddn't think of though.

[joshmoore]

Change of the main branch also require a small number of setting changes to add branch protection etc.

[QuLogic]

Instead of #2341, we could delete the main branch, and rename v3 to main, which will definitely update the PRs to point to main?

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 main now though.

[jhamman]

Here's the behavior we should expect:

Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#about-pull-request-merges

[QuLogic]

Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch.

This does not describe the same scenario as @dstansby suggested above, which was to delete main, and rename v3 to main. The GitHub docs are talking about a PR for branch foo that is merged into main and then deleted, and a second PR that targets foo (not main), which gets automatically re-targeted to main. That is, this is about chained PRs (head branches that are acting as base branches for other PRs), not (base) branch deletion in general.

[jhamman]

@QuLogic -- you are correct. I should have been more explicit. I do not think we should delete main. Instead, we should merge v3 into it and then delete the v3 branch. PRs that are currently pointing at v3 will be automatically re-targeted to main.

@dstansby - how does that sound to you?

[dstansby]

It seems like that will work - for some reason I can't put my finger on I think deleting main and renaming v3 to main will be a bit less likely to go wrong, and will definitely preserve all the commit history on the v3 branch. Doing a merge risks accidentally squashing all the commits, and creates an extra merge commit that we don't need.

So I'd say delete main and rename v3 > main, but I may have missed something and if you'd rather do it the merge way that seems fine too 👍

[jhamman]

To avoid the merge commit (and squashing), we could enable rebase and merge for this instance. It is disabled for the repo at the moment but we could relax that rule while we sort this out.

[dstansby]

How will that interact with main already being merged into v3?

Is there an argument not to delete main and rename v3 > main. It still seems like the simplest (> less likely to go wrong somehow) option.

[jhamman]

I'm realizing I have a fundamental aversion to deleting branches :)

How will that interact with main already being merged into v3?

Rebase would simply add the v3 history to main which, as I understand it, is what you want (no squash, no merge commit).

[QuLogic]

Rebase and merge would linearize the history; there are many splits and merges in the v3 history, and I'm not sure that that would work. It also means that effectively every PR targetting v3 will be outdated because they'll be based on the old version of the commits.

Don't let GitHub limitations over-complicate this for you; it's 3 lines on the command line:

$ git switch main
$ git merge v3
$ git push upstream main

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.

[jhamman]

I'm happy to run these commands. I agree they are functionally what we want.

[jhamman]

This has been done (without a rebase or merge commit). Closing.

Thanks @QuLogic and @dstansby for the help finding a path through this one.