> Suggestion: can we marshal this into some document, > say on the wiki, that we can refer to later?
I would appreciate this. I haven't had time to fully read and digest this thread yet. The gist Frank posted above really does make me wonder quite what kind of rabbit hole we're going down. Regards, Rob. On 13 May 2013 16:44, Sylvester Keil <[email protected]> wrote: > > On May 13, 2013, at 5:11 PM, Rintze Zelle wrote: > >> On Mon, May 13, 2013 at 10:48 AM, Sylvester Keil <[email protected]> >> wrote: >>> Every processor that supports the new version can still support the older >>> version. >> >> Is supporting one version of CSL that requires support for two >> different algorithms worse than having to support two CSL versions? > > For the CSL implementation it is the same thing, but it *gives you the > choice* to support only the new version. The CSL implementation becomes > simpler. > >>> And what is the big problem of having both 1.0 and 1.1 styles in the >>> repository? >> >> In a single branch? We have trouble enough as it is to explain to >> style contributors how to submit their styles. Would we have 1.0 and >> 1.1 versions of the same style? > > No. As long as the style does not require any 1.1 features it stays at 1.0. > > If it needs 1.1 features it is updated – the 1.0 version can keep existing in > a separate branch like it does now if anyone wants it. > > That's why I said that if there are any changes which absolutely must be > updated by all styles, they should always go into a 'truly' backwards > compatible release. > >> How is that not a nightmare to maintain? > > The difference to what we have now is that you mark the style as updated by > updating it's version number and that you must update all backwards > incompatible parts of a style. This can be a burden, true, but what are the > backwards compatible parts? The ordinals in locales? The conditionals? > > I realize that maintenance is a big issue – we can make it part of the > decision of whether or not to include a backwards incompatible feature. For > example, we could try to write a script which updates the feature in question > ahead of time and only if we know that we can update styles automatically do > we agree to drop support for a legacy feature. > > For example, ordinals and conditions: if we have a script that updates > locales and styles to the new syntax, we could drop the old syntax from a 1.1 > release. CSL implementations could still implement 1.0 in order to keep > supporting old styles – it's essentially the same as specifying two variants > in the spec but going forward the spec is lighter and implementations can > make use of the version number to have much cleaner separations of > alternative algorithms. > >> And if you're proposing to use multiple branches, we already >> do that: https://github.com/citation-style-language/styles/tree/1.0 >> (which is about as much proof as I can give you that nobody is >> interested in maintaining 1.0 styles). > > I think the legacy branches are a good pragmatic approach. > >> >>> The ordinal solution now is awkward – the processor can't make use of the >>> version number and needs to look closely at the ordinal terms to decide >>> which algorithm to use. >> >> I guess we could have allowed for a "1.0.1" value on the "version" >> attribute. But that would have meant either bifurcating the schema to >> support validation of both 1.0 and 1.0.1 styles/locales, or using >> separate versions of the schema for validate the respective versions >> of styles and locales. Both would be a headache. > > Like with the styles, what is the problem of keeping a 1.0 version of the > schema around? When validating a style you must check the style's version and > validate against the appropriate schema. It's not a problem at all to built > this into the QA tests – in fact I had it implemented already, because I had > been unaware that the 1.0.1 value was not used. > >>> Why do we even use version numbers if we can't use them? >> >> For "major" updates, like a 1.1 release. (which might not be the right >> approach) >> >>> to keep the implementations backwards compatible. If you put all that into >>> the spec, however, it will become more convoluted with every release. >> >> We would strip any "old" algorithms from the spec on every "major" >> backwards-incompatible release. > > I was not aware of that : ) > > This makes it much easier for me to swallow the 'backwards compatible by > retaining old variants' approach for minor releases. > > Sylvester > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
