> I've proposed creating a branch for all of this work in order > to protect the trunk from any of the major changes. Working > with branches in SVN is *tremendously* easier than in CVS. > This is what is driving the conversion from CVS -> SVN. If > that's not a development reason, then I don't know what is.
We all know (including myself) that working with branches is tremendeously easy when it comes down to simple (text book) scenarios where you create a bug fix branch, make some changes in isolation (whilst leaving trunk more or less untouched) and the merge your changes back to trunk. *In real life*, things are not always that easy, and especially with the structural changes proposed by yourself, I am almost 100% sure that it will come down to manually merging code, especially in the context of an imminent 1.0 release. In real life, we will have to deal with some (hopefully not many) regression issues after the 1.0 release. Whilst we are trying to keep all scenarios in mind when testing before this release, some bugs will show up, and need to be fixed. And this will necessarily happen on trunk, whilst you plan to make (structural) changes to the code base to adopt Castor as described by yourself. In other words, I'd prefer for this to happen after 1.0 release, and I'd like to see some of those changes to be realized in such a way that they do *not* happen in isolation on a branch, but for the benefit of the complete project as soon as possible after the changes have been completed and *before* you embark on implementing JAXB 2.0 functionality. Just to avoid any confusion: I really dig the idea of seeing Castor comply with the JAXB specification, but I'd rather not put the quality of the imminent 1.0 release (and subsequent minor releases) at risk by introducing those changes now (wrongly assuming that creating a branch is sufficient for creating perfect isolation). We are talking about 4 weeks of delay (which in the lifetime fo an open source project is pretty much nothing .. ;-)), and I am sure you can easily bridge this time by familiarizing yourself with the spec, thinking about architecture, engaging in meaningful discussion (about e.g. what decisions to take, how to break things up, ..) and *even bettr* helping the rest to make the 1.0 release what it is meant to be: a high quality, thoroughly tested 1.0 release with some new functionality and loads of bugs fixed. Werner Guttmann Castor JDO, technical lead ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
