OK, then - let's try it on for size. I've created a "staging/0.9.10-incubating" branch off current master for repositories which are release-specific: incubator-guacamole-client, incubator-guacamole-server, and incubator-guacamole-manual. We can promote the branch to a solid "0.9.10-incubating" tag once the release is actually approved.
I did not make such a branch for incubator-guacamole-website, as the website is not tied to the release, but rather to the current state of the project as a whole. We should be good to resume merging contributions to master. - Mike On Tue, Nov 8, 2016 at 1:33 PM, James Muehlner <[email protected]> wrote: > I have to say that I'm usually not a big fan of doing a release branch like > this, but I'm willing to give it a try in this instance. If we can get the > release done soon, it might not really be necessary, but since it's unclear > when exactly that will happen, it might be worth it to unblock those > pending PRs. > > Overall I don't feel strongly one way or another about this. > > James > > On Tue, Nov 8, 2016 at 12:06 AM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi > > > > It sounds good to me. It's basically what we do in most of other Apache > > projects. > > > > Regards > > JB > > > > > > > > On Nov 8, 2016, 08:16, at 08:16, Mike Jumper <[email protected]> > > wrote: > > >Hello all, > > > > > >We have a few pull requests which have been blocked for quite some > > >time due to a combination of: > > > > > >1) The pre-release code freeze > > >2) The slow process of figuring out how to perform releases under the > > >Incubator > > > > > >Given that we're using a version control system perfectly suited to > > >non-linear development, I feel like this sort of situation shouldn't > > >block us. > > > > > >For the sake of keeping things moving and not continuing to block the > > >community, perhaps we should create a release-specific branch off > > >master? > > > > > >Such a branch would be kept around until the release is actually out, > > >receiving only release-specific changes, which would be merged to > > >master as well. Meanwhile coding against master could continue without > > >further interference. > > > > > >Thoughts? > > > > > >- Mike > > >
