+1 If we do this, then it is also fairly easy to do such a patch release, as you just create a branch from the tag (e.g. following 2.2.0 you create the 2.2 branch), and then cherry-pick from the pull requests you need; if we always merge them with --no-ff each such merge will have a pointer to the previous master commit it is based on. (But you could also see this by looking it up in GitHub).
This may require more work if a pull request depends on other changes since the last release, as unlike git merge they would not be included in a cherry-pick. On 11 Nov 2016 11:03 am, "Ian Dunlop" <[email protected]> wrote: > Hello, > > So maybe we just have a policy of always creating a branch for pull > requests. Then if no one merges it within a week you can merge it > yourself. This means that any contributors can just branch off master. > Then we can create a branch for releases as well based off master. I'm > not sure how we would deal with fixes that need to be applied to a > release, some git fu may be needed to sort that one out. > > Cheers, > > Ian > > > On 07/11/16 14:33, Stuart Owen wrote: > > > > > > On 07/11/16 14:15, Alan Williams wrote: > >> On 07-Nov-16 13:45, Gale Naylor wrote: > >>> I was thinking the master was the latest release, too, but I have no > >>> strong > >>> feelings either way. > >> > >> I think the releases are tagged on the master branch, and the master > >> branch is the main development one, with "side" branches for new > >> features. That is how it is done in, for example, > >> incubator-taverna-commandline. That is also how other open source > >> projects I use work. > >> > >> It does have the drawback that you cannot easily be preparing a > >> release and continuing to develop at the same time. I don't think we > >> have a large enough community to worry about that though. > > I've always worked with having the 'master' branch for main > > development, working on feature branches and branches for preparing > > releases. There is nothing to prevent work continuing when preparing a > > release, as you just fork off a branch for that release version and > > start stabilizing and polishing it, whilst risky new development > > continues on the master branch. You also then always have a branch to > > come back to for small bug fixes for past releases which get > > increasingly more stable. > > > > Keeping development on the master branch also has the advantage of > > making your project appear as active as it is, and also makes it > > simpler for pull requests. > > > > Stuart. > >> > >> Alan > >> > >> > > > > >
