On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
Having two frameworks to keep track of instead of one, each with their own idiosyncracies and release trains, is not making life better for the engineers that have to maintain that kind of a beast.
Well, it would have made Atlassian's life easier. JIRA is written with WW1 and Confluence is written with WW2, the two versions cannot coexist in the same web application, and they still haven't gotten around to migrating JIRA. When people (like me) run both applications, we need to run them as two separate web apps, instead of two "modules" that can share session. If I have a work-in-progress that hasn't shipped, sure I'd be tempted to migrate it all to the next major release. But, that's OK, because it's a work-in-progress and it hasn't gone through final acceptance testing yet. (In some shops, the acceptance test phase can take six weeks or more.) If I've already shipped something, and we go from 1.x to 2.x of *anything*, it's going to mean doing the acceptance tests all over again. (At least if I like my job!) Not only Struts, but also a *major* release of any other framework I might use, like Spring or iBATIS or Java itself. Even if the vendor says "nothing breaks", a sane engineer folds his or her own parachute. Albeit, if we need to add some new features, and the two major versions can coexist, we have the opportunity to do the new features in the new version, since these features will be tested independantly. Ditto for significant bugs. If we're reworking something to cure a bug that's going to go through acceptance testing, then we could rework it in the new version. At some point in time, my own application is going to go through a major release of its own. When that happens, we would consider bringing over the rest of the application to the new version too. But, by then, we've done enough work in the new version that we can make an intelligent estimate of how long it will take, and what sort of problems we might have. The important element in this equation is that *we* get to choose what *we* want to migrate when. It can be everything, or it can be some things now and some things later, but we get to choose. My own preference would be to follow Frank's general strategy. We continue to migrate our own applications, document the correlations, and then maybe develop some text-processing tools to automate the mapping. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
