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.

Sign up for GitHub

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

Branching guidelines into CONTRIBUTING.md #2915

Closed
wants to merge 1 commit into from
Closed

Branching guidelines into CONTRIBUTING.md #2915

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,18 @@ If submitting a PR consisting of documentation changes only, please try to ensur

The development team will be happy to help and guide you with any of these points and work with you getting your PR submitted for approval. Create a PR with [WIP] in the title and ask for specific assistance within the issue, or contact the dev team on any of the channels below.

# Branching Model

Grin's current branching model is as follows:

`master` is used for development of the current point release. For instance, if the last released version of Grin is 1.2.0, master will contain changes intending to go into 1.2.1, 1.2.2 etc. Breaking and backwards-incompatible changes should not occur between point releases, and should not be merged into master.

lehnberg marked this conversation as resolved.
Show resolved Hide resolved
The repository will contain a branch from the next upcoming minor or major release. If `master` contains changes for the 1.2.x series and the next planned minor release is 1.3.0, there will be a branch called `milestones/1.3.0` into which all breaking changes intended for 1.3.0 should be merged.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to outline a scenario where master is for 1.2.x, there's a (frozen) milestones/2.0.0, and how people are supposed to do work that is targeted for a post 2.0.0 world?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current situation is fairly unique where we have a long and frozen 2.0.0, and I wouldn't expect it to be the norm (at least I'd hope not), so not sure explicitly outlining this scenario is needed right now. Of course, this could change

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oki. What triggered my question, is that based on the current contents of the document, I can't deduce how this is meant to be handled. It also doesn't feel like an edge case to me, given that we have at least three more of these scenarios scheduled over the next 18 months.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot of conflicts risk involved in working on top of two moving branches but we could add a script in the repo that brings a dev branch up to date with a post 2.0.0 world (git checkout milestones/2.0.0->git checkout -b mybranch->git merge master)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current situation whereby we've essentially frozen all development other than work that's directly hard-fork related is a contingency measure. I'd hope we get our panning together a bit better for future HFs so as this situation won't be repeated. That's why I'm not keen on putting together guidelines that reflect the current situation.

Periodially, (and particularly in a situation where minor/major releases are undergoing a long development cycle), changes from `master` should be commit into the current major/minor branch so as to avoid a large, messy merge before release.

Just before a major or minor release, the development branch is merged back into `master`, tested, tagged and released. It then becomes the new master for point releases in the series. The previous major/minor branch is deleted, and a new branch is created with the version number of the next anticipated major/minor release.

# Find Us

When you are starting to contribute to grin, we really would appreciate if you come by the gitter chat channels.
Expand Down