On Tue, Jan 10, 2012 at 6:15 PM, Charles Parnot >> Having branches for processors is indeed an option, though it's up to the >> implementor of that processor. It's not too hard to support both in this >> case, and makes testing much simpler if you only have one branch. >> >> Now, where branching could make sense is actually with the styles >> themselves. I now see why allowing 1.0.1 styles in the master could be >> problematic: as the spec change, that would mean checking all the styles >> again, making changes, and potentially messing up some of the styles that >> were otehrwise perfectly stable in 1.0. So instead, adding a branch to the >> CSL style repo could make sense. That branch would only contain files that >> have 1.0.1 features (so the branching should be done from the empty base of >> the tree, not from HEAD). Then we could start pushing changes on that >> branch. Each implementor could decice wether to include that branch (for >> instance, to be honest, Papers would likely also pull from the 1.0.1 >> styles). Changes in the 1.0.1 specs can be applied to just that branch, and >> thus just those few styles. Later, those styles can be merged back into >> master, which becomes 1.0.1 >> >> Charles
On Jan 10, 2012, at 2:07 PM, Frank Bennett wrote: > For legal and multilingual style development, I have a development > fork going at https://github.com/fbennett/schema. The diffs for some > of the extensions are interdependent, and when trying to maintain > atomic commits for each feature, I ended up with cascading > sub-branches of contingent feature sets. It because quite hard to > follow, and I've given that up in favor of other work; > > It could be that I'm not using git correctly, though. I have a sort of > love-hate relationship with the tool, and there is a lot of > misunderstanding. :) Indeed, branches can get a bit complicated, particularly if the branches are used by several people, and if rules on their use are not explicitly spelled out. But it occured to me we could maybe instead use the following trick, which would allow (1) to stick to 1.0 CSL validation in the repository, (2) easily switch to 1.0.1 support when it's ready, (3) make it very clear in the CSL itself what is happening and (4) allow the clients to postprocess the CSL files to their liking in the meantime. That's a bit hacky, but maybe you will all like it and want to adopt it, who knows :-) So the idea would be to use comments for those, which I noticed is already done, but in a more standardized way. Here is what I am thinking about for instance: <macro name="author"> <names variable="author"> <!-- 1.0.1 ADD BEGIN <name name-as-sort-order="all" sort-separator=" " initialize-with="" delimiter=", " delimiter-precedes-et-al="never"/> END --> <!-- 1.0.1 REMOVE BEGIN --> <name name-as-sort-order="all" sort-separator=" " initialize-with="" delimiter=", "/> <!-- END --> <label form="short" prefix=" (" suffix=")" strip-periods="true"/> <substitute> <names variable="editor"/> <names variable="translator"/> <text macro="title"/> </substitute> </names> This should be fairly easy to automate. It also clarifies the intent to anyone reading the XML directly. What do you think? As a test, I have changed this style in the repo (the resulting CSL is the same, just the way things are commented has changed): https://github.com/citation-style-language/styles/commit/ea7bc629177f67a26f1fc9c28ce6db03a1010863 Charles ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
