Status page for style repository

CSL Development
61

To be clear: branches would be “deprecated” asap, and we would stop maintaining them (committing to them) when all clients are updated. The older branches would be eventually buried in history, and with very explicit naming like 1.0.1, I don’t see where confusion could be. Keeping ‘master’ as the current latest styles for a given CSL version would also be a very nice way to make it idiot-proof to get the latest styles for the most up-to-date clients at any given time.

Also, looking at the history of CSL, you guys have been quite conservative, and I mean this in a good way. So it does not look like we are going to create branches nilly-willy every week. I think we still have a long time before we have a ‘plethora’ of branches :wink:

Finally, I don’t have the experience of going from the 0.8.1 to the 1.0 version of the styles. Whatever you guys learnt from it should be taken into account, but I can’t speak much on that.

It can definitly help to explicitely stating rules for expected changes between minor versions of the CSL, like restricting changes to only adding new attributes or adding new options for given attributes. Now, if you change the default value of an attribute, that does not break a client, but it certainly makes it behave wrongly, yet it could be considered a minor change.

There is potentially the issue of adding an attribute or an option that makes it much easier to deal with certain rules, in a way that would have been possible, but painful in 1.0. So you’d want to edit old styles or create new styles with those simplified attributes. These styles will work perfectly with 1.0.1 clients, but will produce a worse output on 1.0 client, even though that could be prevented by using the complicated workaround and still have the same output with 1.0.

Maybe these are not actual possibilities, but I am just wondering if even minor changes can still result in 1.0.1 styles being a step back for clients still expecting 1.0. And I am pointing this out because even if those cases, a separate branch would ease the transition.

Bruce, in any case, you have not explicitely stated how you see the transition going. Do you mean maybe that at some point X in time, we decide from now on, we can have 1.0.1 styles in the ‘master’ branch and that’s it? That’s definitely an option, but I don’t know if this is what you have in mind.

charles

62

Yeah, just to clarify, I thought we had previously agreed on plans for
versioning, which effectively meant that we’d only consider style branches
for major point releases.

63

I think we did say it would be a good idea, but I am not sure we have the OK from all current implementations, for the 1.0 to 1.0.1 transition.

We also have not formally listed what changes would be considered minor. I am not knowledgeable enough about the development of CSL specification to have much to say about it.

Papers: very likely OK (depenbing of what we formally consider minor changes).

charles

64

CSL 1.0.1 will be backward compatible, but won’t be forward compatible.
I.e., any valid CSL 1.0 style should work correctly with a CSL 1.0.1
processor, but a CSL 1.0.1 style won’t necessarily render correctly in a
CSL 1.0 processor.

Take for instance the new “available at” term. CSL 1.0 clients that have
shipped with CSL 1.0 locales won’t have that term in their locale files,
and any CSL 1.0.1 style that calls this term will at best render an empty
string (unless that style happens to define the term with cs:locale).

Another example is the Zotero Style Repository. If we introduce styles with
CSL 1.0.1 features in the “master” branch, these styles will appear to be
invalid in the Zotero Style Repository. Things would be much more robust if
Zotero could just pull their 1.0 styles from a “1.0” branch, and move
branches once they’re ready for “1.0.1”.

And, as you said above, branch are light-weight.

Rintze

65

Sylvester just implemented a new progress indicator that forgoes all the
periods/dots. See e.g. the output at
http://travis-ci.org/#!/citation-style-language/styles/builds/2101491

Rintze

Screen shot 2012-07-19 at 8.05.31 PM.png580×512 8.22 KB

66

Never replied to this. I understand this, but don’t think it’s a good
situation to be in.

67

I welcome any suggestions to do it better.

Rintze

68

I think your point probably suggests a solution: decouple style versioning
from the evolution of a) the basic language, and b) things like locales?

69

How would that work, exactly?

70

Random thought:

a) we simply don’t consider the terms schema part of the same
versioning scheme, b) define how implementations should deal with
unknown terms, and c) leave it up to those implementations to keep
their locales files up to date (it’s really not our job to worry about
that).

Isn’t that a viable, simple, approach?

71

I have a hard time seeing any advantages of such an approach, but please
prove me wrong.

When we introduce new terms, style authors should be confident that those
terms have translations in the locale files, and, AFAIK, none of the CSL
apps support automatic style updating, let alone locale updating. Just
dismissing that as being the problems of the implementations doesn’t seem
like a workable short-term solution.

Uncoupling the addition of new terms from schema updates also doesn’t solve
the current case where we add new terms for ordinals, since they require
new logic in the CSL processor.

Rintze