I added a style for ‘Mammal Review’ contributed by a Papers2 user. She said she had tested it also in Zotero, where the attribute delimiter-precedes-et-al is supported and works as expected. However, since it is not part of CSL 1.0, it would not validate with the 1.0 schema. So I have commented it that attribute at the moment in the repository.
It is not so much an issue with Papers, since we don’t support the attribute. So basically the style will behave the same with or without the attribute. But for Zotero users, that means they could have something a little better if that line was commented out in the style repo. I realize this comes back to the question of transition that was raised the other day. To clarify again, having 1.0.1 attributes is fine with Papers2. So if other implementations are fine too, then we could maybe switch to 1.0.1 for validation.
Fingers crossed that this style has no issue btw. That would be a first!
My main reservation is that I pushed for some new features for CSL 1.0.1
that are in the trunk schema and spec (and in most cases supported by
citeproc-js), but which haven’t received a lot of review from the other CSL
developers/implementors, so CSL 1.0.1 final might look a bit different. So
until we release CSL 1.0.1 I’d like to hold off on adding styles to the
repo with 1.0.1 features.
We could move to a more agile development track, where we green light and
implement features on a case-per-case basis, but that’s another discussion.
RintzeOn Tue, Jan 10, 2012 at 12:13 PM, Charles Parnot <@Charles_Parnot>wrote:
Maybe instead of adding new features on trunk (well, really master;
trunk is CVS/SVN language), maybe we ought to do those on branches?
Features then get merged to master whenever they get cleared by X
number of developers, without any objections?
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
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
For legal and multilingual style development, I have a development
fork going at GitHub - fbennett/schema: Citation Style Language 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.
