Branching guidelines into CONTRIBUTING.md #2915
Conversation
| `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. | ||
|
|
||
| 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. | ||
|
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
Add description of current branching model into CONTRIBUTING.md (avoiding shame at upcoming meeting)