Skip to content
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

Closed
2 of 3 tasks
jhamman opened this issue Oct 8, 2024 · 23 comments
Closed
2 of 3 tasks

Moving v3 development to main #2308

jhamman opened this issue Oct 8, 2024 · 23 comments
Labels
V3 Affects the v3 branch
Milestone

Comments

@jhamman
Copy link
Member

jhamman commented Oct 8, 2024

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.

@jhamman jhamman added the V3 Affects the v3 branch label Oct 8, 2024
@jhamman jhamman added this to the 3.0.0 milestone Oct 8, 2024
@d-v-b
Copy link
Contributor

d-v-b commented Oct 8, 2024

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

@joshmoore
Copy link
Member

  • 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
Copy link
Member Author

jhamman commented Oct 10, 2024

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

Left to be determined. Open to opinions.

@dstansby
Copy link
Contributor

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

@jhamman
Copy link
Member Author

jhamman commented Oct 10, 2024

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
Copy link
Contributor

👍 sounds good, for anyone brave enough to try 😄

@joshmoore
Copy link
Member

for anyone brave enough to try 😄

😄

    git clone git@github.com: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 jhamman mentioned this issue Oct 10, 2024
6 tasks
@jhamman
Copy link
Member Author

jhamman commented Oct 10, 2024

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:

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
Copy link
Contributor

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?

This was referenced Oct 11, 2024
@jhamman
Copy link
Member Author

jhamman commented Oct 12, 2024

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
Copy link
Contributor

dstansby commented Oct 13, 2024

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
Copy link
Member

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

@QuLogic
Copy link
Contributor

QuLogic commented Oct 13, 2024

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
Copy link
Member Author

jhamman commented Oct 13, 2024

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
Copy link
Contributor

QuLogic commented Oct 14, 2024

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
Copy link
Member Author

jhamman commented Oct 14, 2024

@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
Copy link
Contributor

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
Copy link
Member Author

jhamman commented Oct 14, 2024

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.

image

@dstansby
Copy link
Contributor

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
Copy link
Member Author

jhamman commented Oct 14, 2024

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
Copy link
Contributor

QuLogic commented Oct 14, 2024

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
Copy link
Member Author

jhamman commented Oct 14, 2024

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

@jhamman
Copy link
Member Author

jhamman commented Oct 14, 2024

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
V3 Affects the v3 branch
Projects
Status: Done
Development

No branches or pull requests

5 participants