With experience from other projects, releases are often best when created from a branch intended for that purpose. In a simple project, you have one such branch: usually trunk. More complex projects with longer support cycles will have several. I think it is useful to put release candidates on their own branches so that release work and normal support don't interfere without someone explicitly deciding to make that happen, but I would not be displeased if we weren't as fussy. 😉
Once we know the exact commit that corresponds to a release, we must push a tag in. Of course. It is also a useful check to then do an independent checkout of that tagged version and do the build off that. (Both official source tree and unofficial binary build.) CI servers are good at that. Donal. On 13 Nov 2016 08:21, Stian Soiland-Reyes <[email protected]> wrote: > > +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 > > >> > > >> > > > > > > > > >
