On Tue, Jul 24, 2012 at 12:49 PM, Simon Kornblith <[email protected]>wrote:
> On Jul 24, 2012, at 12:27 PM, Rintze Zelle <[email protected]> wrote:
>
> On Thu, Jul 19, 2012 at 5:40 PM, Sylvester Keil <[email protected]>
> wrote:
>
>> Another question we should keep in mind whether it may not be easier to
>> work on the master branch and have separate release branches? Especially if
>> we may want to keep separate versions of styles in the future (i.e., 1.0
>> branch, 1.0.1 branch).
>>
>
> I think nobody objects against having separate branches for the different
> CSL releases. The minimal branch structure would then be: "0.8.1", "1.0",
> "1.0.1" (and so on), "master".
>
> To enable people to subscribe to a CSL branch without having to worry that
> this cloned branch changes version (which would happen in "master" with our
> current setup ), we would need a branch for the current CSL release, in
> addition to branches for older CSL releases.
>
> That arrangement by itself however doesn't solve the problem of preventing
> invalid styles from ending up in the version branches, and we'll likely
> want to be able to accept patches for older CSL versions. I can think of
> two options here:
>
> a) we keep using "master" for accepting CSL styles of the most recent CSL
> version, and allow direct commits and merging of pull requests with invalid
> CSL styles. We also accept pull requests to version branches of older CSL
> releases, but only once Travis CI has checked them. A GitHub service hook
> can be used to check the "master" branch after each commit, and push the
> commit to the most recent CSL version branch if there are no errors (the
> service hook script can either wait for Travis CI or run the tests itself).
>
> b) we keep using "master" for accepting CSL styles of the most recent CSL
> version, but only accept pull requests. We also accept pull requests to
> version branches of older CSL releases. In both cases, we would only merge
> pull requests once Travis CI has checked them. A GitHub service hook can be
> used to automatically push any changes made to "master" to the most recent
> CSL version branch.
>
> The downside of only relying on pull requests is that fixing small errors
> can be cumbersome (you have to download the file(s) by hand via the GitHub
> web interface), because the CSL team members typically won't have commit
> access to the fork of the person making the pull request. In some cases it
> might be easier to accept broken styles and fix them up after merging.
>
>
> I like the second approach, but in that case, I'm not sure a master branch
> is necessary at all. GitHub allows you to rename the master branch and set
> a different default branch for a repository. The master branch could also
> be a symbolic-ref to the most recent version branch.
>
> You can fix small errors before pushing to the repository if you merge
> pull requests the command line way:
>
> git fetch git://github.com/<<USER>>/styles.git
> git merge <<COMMIT HASH>>>
> # Fix and commit fixes
> git push
>
Good to know, and I agree that mirroring "master" against the most recent
CSL release is unnecessary. However, we might want one additional branch
(which can be either "master", "development", or "experimental") to accept
styles that validate against the schema trunk. It might be handy to have
some styles available for testing before an official CSL release (the
current policy is to reject CSL 1.0.1 styles, since everything in the
"master" branch should validate against the CSL 1.0 schema).
Rintze
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
