Having branches for processors is indeed an option, though it's up to the implementor of that processor. It's not too hard to support both in this case, and makes testing much simpler if you only have one branch.
Now, where branching could make sense is actually with the styles themselves. I now see why allowing 1.0.1 styles in the master could be problematic: as the spec change, that would mean checking all the styles again, making changes, and potentially messing up some of the styles that were otehrwise perfectly stable in 1.0. So instead, adding a branch to the CSL style repo could make sense. That branch would only contain files that have 1.0.1 features (so the branching should be done from the empty base of the tree, not from HEAD). Then we could start pushing changes on that branch. Each implementor could decice wether to include that branch (for instance, to be honest, Papers would likely also pull from the 1.0.1 styles). Changes in the 1.0.1 specs can be applied to just that branch, and thus just those few styles. Later, those styles can be merged back into master, which becomes 1.0.1 Charles On Jan 10, 2012, at 9:58 AM, Bruce D'Arcus wrote: > On Tue, Jan 10, 2012 at 12:50 PM, Rintze Zelle <[email protected]> wrote: >> On Tue, Jan 10, 2012 at 12:13 PM, Charles Parnot <[email protected]> >> wrote: >>> >>> So if other implementations are fine too, then we could maybe switch to >>> 1.0.1 for validation. >> >> >> My main reservation is that I pushed for some new features for CSL 1.0.1 >> that are in the trunk schema and spec (and in most cases supported by >> citeproc-js), but which haven't received a lot of review from the other CSL >> developers/implementors, so CSL 1.0.1 final might look a bit different. So >> until we release CSL 1.0.1 I'd like to hold off on adding styles to the repo >> with 1.0.1 features. >> >> We could move to a more agile development track, where we green light and >> implement features on a case-per-case basis, but that's another discussion. > > Maybe instead of adding new features on trunk (well, really master; > trunk is CVS/SVN language), maybe we ought to do those on branches? > Features then get merged to master whenever they get cleared by X > number of developers, without any objections? > > Bruce > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel -- Charles Parnot [email protected] twitter: @cparnot http://mekentosj.com ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
