Re: Getting Started

> 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