On Tue, Jan 10, 2012 at 6:15 PM, Charles Parnot <[email protected]> wrote: > 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
For legal and multilingual style development, I have a development fork going at https://github.com/fbennett/schema. The diffs for some of the extensions are interdependent, and when trying to maintain atomic commits for each feature, I ended up with cascading sub-branches of contingent feature sets. It because quite hard to follow, and I've given that up in favor of other work; It could be that I'm not using git correctly, though. I have a sort of love-hate relationship with the tool, and there is a lot of misunderstanding. :) Frank > > > 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 ------------------------------------------------------------------------------ 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
