On May 13, 2013, at 3:42 PM, Rintze Zelle wrote: > On Mon, May 13, 2013 at 3:11 AM, Sylvester Keil <[email protected]> wrote: >> If a feature differs so much that the underlying syntax changes or that new >> elements need to be created, I don't think it's fair to call it backwards >> compatible. Such a feature should go into a major release and the legacy >> feature should be dropped completely. By doing this you're actually >> *helping* implementers to provide backwards compatibility, because they can >> simply look at a style's version and tell whether they need to follow the >> 'new' or 'old' way. > > With the CSL 1.0.1 release, we had a similar issue with the algorithm > for ordinals, as you're well aware. But if we had done what you > propose, and drop the "old" algorithm from the spec, we would either > have had to: > > - drop the feature from CSL 1.0.1 and release it as a 'clean' > backwards compatible release; > or > - release 1.0.1 as a backwards incompatible release. That would have > involved the need to update all the existing styles in the repository > to the new logic.
You only need to update the styles, because you're not allowing a version number of 1.0.1 on the style; or, alternatively, because you're releasing it as 1.0.1 instead of 1.1. Every processor that supports the new version can still support the older version. By checking the CSL version number of each style it is easy to differentiate between the two. And what is the big problem of having both 1.0 and 1.1 styles in the repository? If the problem is that there were critical bugfixes in 1.0.1 which required all styles to be updated then there should actually be two releases: one bugfix 1.0.1 and a new stable release 1.1 which also includes the new features. This way only styles or locales that require the new feature need to be updated to the latest release version. 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. Why do we even use version numbers if we can't use them? Again, all I keep saying is this: Even if the spec is not backwards compatible, the cite processors still *can* and probably *will* support multiple versions. You keep citing the problems of CSL-implementations and their users – but this is not really the problem of the specification, but of the implementations. All the implementers are here in this forum, it's not like anyone would be taken unawares by a release. And don't get me wrong: I think you're doing a great job by caring so much for backwards compatibility – if I say we shouldn't enforce it in the spec it doesn't mean that we can't share strategies etc. of how to keep the implementations backwards compatible. If you put all that into the spec, however, it will become more convoluted with every release. 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
