Hi James, This looks like an excellent--and ambitious--roadmap to me!
James Berry <[EMAIL PROTECTED]> wrote on 02/08/2005 09:56:00 AM: > I agree that we should move to the future and shed old baggage. Moving to the future is always good. I am a bit confused though about what "old baggage" we need to shed, and just what shedding implies. The deprecated DOM, for instance, is now built into a separate library; folks that don't need it have no reason to deploy it. Does the inclusion of that unquestionably elderly code in our build manifestly cause anyone pain? If there is other code--aside from things like demonstrably useless enums--that is annoying people, perhaps we could mete the same treatment out to it? > > I propose that we create a 2.6.x branch, and get CVS HEAD headed toward > a 3.0 release, covering the latest version of the spec, which might be > unstable for a while. > > Perhaps this would also be a good time (pre-branch) to move to > subversion? It does a lot better job of dealing with deleted and > reorganized files, directories, etc. > > Proposed sequence: > > (1) Move to subversion. I agree that this is beneficial and inevitable. We have clear direction from the Infrastructure team that all projects will eventually be presented with an offer they can't refuse along these lines. That said, as a Cygwin user and a command-line devotee, I'd love to be assured there's hope for my preferred method of code extraction. (Mind you, given the amount I'm committing these days, that hardly matters! :) ) > > (2) Create xercesc 2.x branch for any further 2.x bug fixes or > development > > (3) HEAD will begin work toward a 3.0 release which sheds old > interfaces, etc. Reiterating the above, I'd like a bit more clarity about the old interfaces we'd like to shed, and just what shedding implies (as well as why it's needed, if shedding == deletion from the source tree). DOM level 3 certainly does sound like something we should be aiming to support. Looking back at some notes from early 2003, the stimate was that Core would have cost about 3 person months, and load/save about 1 month; given that there has been further divergence since, it's somewhat hard to imagine that these numbers are not conservative. So, before committing ourselves to this course, or to a schedule, it seems to me prudent to estalish that there are volunteers who are able to undertake the necessary work at present. > (On thing I'd love to see resolved for 3.0 would be a re-work of the > configure/build infrastructure and ports. Xerces would gain a lot more > mindshare if it had a cleaned up ./configure/make/make install build, > and a way to lose all of the redundancy that creating a port currently > requires.) I'm very much ready to admit my ignorance of other build architectures. It sure does seem that Xerces-C is supported on lots of platforms and compilers; given that there is a certain amount of investment in the existing infrastructure, I for one would sure be appreciative of some education as to the advantages of alternatives, as well as what's necessary in terms of migration for tooling (build systems etc.) that centre around what we currently have. Understanding a bit more concretely what's wrong with what we currently have would also sure be helpful. Those are a few things that occur to me at first glance anyway. The overall direction of this proposal is good; just want to make sure all the details are accounted for. Cheers! Neil Neil Graham Manager, XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
