-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
4.0 | Rename master branch to stable #3
Comments
About the renaming, I think it's a good idea, about the default branch… I'm not sure. In |
@greg0ire Thanks for your input. I'm going to have to have a think about that.
If I understand you correctly, you mean that My intention is to use The one thing I really don't want is to have long running "next major" branches, as is currently the case with the four year running |
Yes exactly I misunderstood what
Ok so, if I understand correctly, this workflow is going to lead in a situation more similar to what firefox does, where there are major releases very often?
That looks a lot with what I had to do with all the backports from 3 to 2. I feel your pain. |
I'd like to know how you handle bug fixes, new features, and BC breaks in PRs using a single branch. In cases where the |
@greg0ire It's akin to a git-flow workflow, but not as strict ;-)
Well, hopefully not with that much version inflation, but yes, I do intend to allow for more regular majors when the situation calls for it. I have a rough outline of a roadmap/plan for 4.0 -> 5.0 -> 6.0 already, but the first focus in that regards is getting 4.0 in a releasable state, so I don't want to share too many ideas for the future at this time for fear of overpromising.
@asispts Well, delays like that may sometimes happen, but I would mostly try to avoid them by planning out merges carefully, similar to what has been done in this repo in the past. If you look at the open PR list now, there are some things milestoned for When getting close to the next major, I would create a 3.x branch for the final patch/minor releases of the old major and then let And yes, even though I could push straight to the
Does that help clarify things a bit more ? |
For me it does 🙂 If I understand correctly, you're "storing" improvements in the next minor milestone, and breaking changes in the next major milestone, and then when the time comes, you merge all at once, probably not with an octopus merge though 😅 I guess you don't wait for too long though because otherwise the merge/rebases must be quite painful. It sounds like a lot of work to be honest, but I suppose it all depends on the actual number of PRs in a milestone, and from what I saw in 3.9.0 there aren't that many (and since you're the author of many of them, and the PRs are recent, it's probably not that hard). 100% agree on using PRs for absolutely every change 👍 |
@greg0ire Correct and yes, I don't intend to let things wait for too long. I also have a GH Actions workflow already set up which automatically labels PRs with merge conflicts, so it's pretty straight forward to see what needs a rebase and if there is one thing I've become good at over the years, it's rebases, so I'm not concerned about the current merge flow and will be happy to revisit if it would become a problem. |
@greg0ire Just read up on octopus merges, hadn't come across that term before. And no, when I do those kind of "merge sprees", I will merge one PR at a time and for all my own PRs, rebase before merging the next one, to make sure that if there is a CI failure due to one change having an unexpected impact elsewhere, it can be easily identified and gets caught before the merge. That's also how I merged my own PRs which had been waiting to be merged in the squizlabs repo (for ages) and which I'd ported over and included in the 3.8.0 release. |
I've done them once in my life, at work, for a merge release train, in a case when I was somehow sure in advance there wouldn't be any conflicts. It was fun but I wouldn't recommend it 🤣 The way you're describing is safer indeed 👍 |
... and add a
develop
branch as the default WIP branch. Thestable
branch will become the release-only branch.The text was updated successfully, but these errors were encountered: