On Sun, Apr 28, 2013 at 11:00 AM, Bruce D'Arcus <[email protected]> wrote: > Do we have a clear policy on this? Does a change like this go in a 1.1 > schema and spec, and do we create 1.1 variants of all 5000+ styles? > > Notwithstanding details, I think this is the core issue I see.
If we come to consensus on this issue, the solution will probably be backward compatible (i.e. the conditional logic of CSL 1.0.1 styles will remain valid syntax). In that case, we can simply do what we did for CSL 1.0.1: - preannounce release of a new CSL version (e.g. 1.0.2), and create a 1.0.1 branch in the "styles" repository - after a few weeks, formally release the new CSL version and start accepting new version styles in the repository This gives any developers who aren't able to accommodate the new CSL version some time to switch to the "1.0.1" branch until they're ready to switch back to "master". >> The even bigger change is probably caused by the 'not:' prefix (at least in >> the Ruby implementation that was the case). > > Right. This is an example that conflicts with current design > foundations in CSL. Yes, and I'm not happy with that proposal :). Rintze ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
