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.
Well, that’s their problem; how hard can it be?
Mendeley guys? Zotero guys? Anyone else?
Just dismissing that as being the problems of the implementations doesn’t seem
like a workable short-term solution.
I guess I’ll go back to my earlier question in reply:
How does having style branches (as well as updated schema and
specification releases) for every trivial (x.x.x) change help anyone?
What work will implementers (or even worse, users) have to do just to
accommodate this approach, and how would that work compare to what I’m
suggesting here (my guess is my suggestion is easier to implement)?
I think we’re overloading the notion of a CSL version change to cover
too many issues.
Bruce
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.
Well, that’s their problem; how hard can it be?
Mendeley guys? Zotero guys? Anyone else?
Bruce: I’m not quite sure what you’re suggesting. Is the idea that
there would be one master styles repo, with the most recent release
version of each style, to be run with processors that groke the most
recent schema and locale releases? Or are you suggesting that style
version branches should only be cast at larger (schema) version
increments?
With respect to locale files, is the idea that a given schema version
should not have a declared dependency relation to a given locale
release? I don’t see how you could avoid that and still keep things
working, but I may be missing your point.
Frank
My 2 cents on those different subjects, mostly from the perpspective of Papers:
-
I like the idea of having a ‘legacy’ branch for styles compatible with the previous version of CSL, just to ease the transition; I don’t think those branches should be maintained for very long (maybe a few weeks), but these would provide a way to fix any important issue with a specific style for clients that are still a version behind (for instance, we may decide to keep CSL 1.0 for a minor version release, and would like to make sure our styles are all good); for the sake of testing how this would work for future transitions, maybe it could be worth giving it a try with the 1.0 to 1.0.1 transition;
-
I would tend to agree with Bruce that we don’t need to tie the terms to a specific version of CSL; we update the locales at every update, and if a user wants to develop a new style with a just added term, well, they’ll just have to wait a bit before it works in Papers; I think the gained flexibility is well worth the annoyance of getting client up to speed; locales would also probably the easiest ones to grab from the repository in a more automated fashion by the app
So I believe I agree with Rintze on the first point, and agree with Bruce on the second 
charles
There are very few cases where new terms are introduced by themselves,
though. In most cases they are accompanied by new variables, or new logic
in the CSL processor. If the goal is to make CSL development more agile,
then there are other ways to do that.
Also, it’s clear that most changes to CSL don’t receive very close scrutiny
from all parties involved at the time they are developed (which I can
understand, as following everything takes quite a bit of time). But because
of that, capturing all changes to CSL into versioned releases, and creating
review periods (like the one we’re in right now for 1.0.1) gives me some
peace of mind, as it provides short time frames where I ask people for
their attention.
RintzeOn Mon, Aug 13, 2012 at 1:09 AM, Charles Parnot <@Charles_Parnot>wrote:
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.
Well, that’s their problem; how hard can it be?
Mendeley guys? Zotero guys? Anyone else?
Bruce: I’m not quite sure what you’re suggesting. Is the idea that
there would be one master styles repo, with the most recent release
version of each style, to be run with processors that groke the most
recent schema and locale releases? Or are you suggesting that style
version branches should only be cast at larger (schema) version
increments?
The latter.
With respect to locale files, is the idea that a given schema version
should not have a declared dependency relation to a given locale
release? I don’t see how you could avoid that and still keep things
working, but I may be missing your point.
I’m not sure of the precise details yet, except to say that we
decouple locales from core schema. It could be that locates get a
separate versioning scheme (maybe by date?).
Bruce
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.
Well, that’s their problem; how hard can it be?
Mendeley guys? Zotero guys? Anyone else?
Bruce: I’m not quite sure what you’re suggesting. Is the idea that
there would be one master styles repo, with the most recent release
version of each style, to be run with processors that groke the most
recent schema and locale releases? Or are you suggesting that style
version branches should only be cast at larger (schema) version
increments?
The latter.
Some of the changes in processor logic this time around are pretty
significant, and tightly tied to specific changes in the locale. What
determines the size of the increment in this case? Is the issue the
number assigned to the release, or the degree of change in CSL?
With respect to locale files, is the idea that a given schema version
should not have a declared dependency relation to a given locale
release? I don’t see how you could avoid that and still keep things
working, but I may be missing your point.
I’m not sure of the precise details yet, except to say that we
decouple locales from core schema. It could be that locates get a
separate versioning scheme (maybe by date?).
So long as we have specific guidance on version dependencies for the
release, the numbering scheme could be anything, I guess. It would be
easier to follow if the branch numbers under schema, locales and
styles were aligned, though.