It’s a nice plan
On Tue, Nov 26, 2019 at 7:10 PM Bobby Bruce <[email protected]> wrote: > Dear all, > > As you know, at the end of this quarter we will be releasing gem5-19, the > first official release of gem5. As part of this release we'd like to change > our git branching structure. Therefore, I'm writing to ask for feedback on > what we have planned and whether it can be improved upon. > > We'd like to have a git repo structure similar to that used in gitflow > development: https://nvie.com/posts/a-successful-git-branching-model . > I've > seen this model work well before, as it has some worthwhile abstractors for > public, open source git projects with regular releases. What I'd like to > incorporate from this model is the following: > > - Two permanent branches: master and develop. > - "develop" would function as master does now. This would be the main point > in which changes are applied between gem5 releases. > - Upon a new release of gem5, the develop branch would be merged into > master and a new git tag added to master indicating the release version. > Ergo, the master branch would always contain the latest release of gem5. > - If a quick hotfix is needed, a new "hotfix" branch would be created and > merged into both the develop and master branches upon completion. This > would also require a new tag on the master branch. (I suggest using the > standard "Version [Major].[Minor].[Hotfix]" version numbering system. I.e., > the first version would be V19.0.0, a hotfix to this would make it V19.0.1, > and a minor release would make it V19.1.0). > - The creation of feature branches would be permitted. These branches would > encapsulate the gradual development of large features (i.e., ones carried > out over many commits). When complete a feature branch would be merged into > the develop branch. They'd be no obligation to use feature branches though > we believe they could be of value in certain cases. For example, if a > developer wishes to postpone a developed feature for a given gem5 release > (e.g., something more suited for a major release rather than a minor one), > then they could submit their changes as a feature branch and wait to merge > to the develop branch at a later date. > > I believe this setup would make our development process run smoother and > give gem5 users more stability. Day-to-day development wouldn't change much > as committing to the develop branch would work in the same way as > submitting to master does now. > > If anyone has any thoughts about this, I'd be happy to hear from you. > > Kind regards, > Bobby > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
