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 >> >> >
signature.asc
Description: OpenPGP digital signature
