So this is the kind of conversation about compatibility, in relation to change management, that I was hoping to prompt with my question.
But we basically have two (or more) related, but also parallel, discussions and issues going on here, and I think we need to clearly separate them. Suggestion: can we marshal this into some document, say on the wiki, that we can refer to later? Bruce On Mon, May 13, 2013 at 11:11 AM, Rintze Zelle <[email protected]> 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? > >> 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? How is that not a nightmare to > maintain? 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). > >> 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. > >> 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. > > Rintze > > ------------------------------------------------------------------------------ > 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
