- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 7 Sep 2015 13:16:24 -0700
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: public-rdf-tests@w3.org
> On Sep 7, 2015, at 12:42 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote: > > Hi Gregg, > > +1 to all, perhaps except: > >> * Some updates, e.g. more extensive updates to the SPARQL test suite, may require branching off of a separate feature branch, so that a set of changes can be staged before updating the main branch. We may want to use a “sparql11-rev-1” branch for this purpose. > > Could we perhaps prefix feature branches, for instance with feature- ? Yes, but I think feature branches better describe fixing a particular issue, while a “release” branch indicates the integration of a set of features targeted for release. For development, I use git-flow, which has such a feature, but I don’t think we should impose this. Sticking to feature- and release- branch names seems pretty clear (Also issue-xxx-, for the response to a particular issue). >> * After a changes to a given test suite become stable, a “release” branch can be created to record the state of the test suite at that time; this also becomes the best target for subsequent implementation reports. > > Shouldn't this be "gh-pages" then? > Or what else will be in "gh-pages"? > Alternatively, it could be just "master" instead of "release”. gh-pages should represent what is currently released; that’s the most convenient thing to access via simple HTTP request. But, I think keeping the release- branches around so that we collect the set of commits used for a given release is good practice. Using this for implementation reporting may impose too great a burden though, if there are more than a couple of releases. Certainly the URI used to denote the individual tests should be consistent across different releases. Gregg > Best, > > Ruben
Received on Monday, 7 September 2015 20:16:55 UTC