I have not read much discussion about issues relating to Jetspeed upgrades for organizations desiring to move from say 1.4.b1 to 1.4-b3. It seems to me that upgrade might be the wrong term, rather migration may be more fitting considering the amount of work that it entails. Last year we had no problem upgrading from 1.3a2 to 1.4.b1 however our portal development was in its early stage of development. During the period of time we were using 1.4.b1 our portal development matured, we coded, implemented and deployed various web enabled applications into the portlets and tested its readiness for a beta release to a hand full of customers. Upgrading to 1.4-b3 turns out to be a significant effort for us.
I would like to find out what guidelines exist regarding Jetspeed development decisions for releases. If there are no guidelines, then I might suggest that it would be a good idea for those involved in developing Jetspeed to pause momentarily and establish a framework or reference that people can go by to judge whether or not they should consider using the latest release. I might be at fault to think that the distance in time and the changes and improvements that have taken place between 1.4.b1 and 1.4-b3 are not that major. And, perhaps the actual Jetspeed code itself, particularly looking at the change log is not enough to scare me away from trying to upgrade. But the real tell tale sign comes when you look at the support software infrastructure for the project (aka Supporting Projects). Upgrading Turbine and Torque which has been rolled into the 1.4-b3 release has greater consequences than anything listed in the change log for the release. And while this thought might be controversial, I think it might be more meaningful to the community to know that if you migrate to upgraded versions of such things as Turbine and Torque, you really ought be doing so at a major point release. The justification for doing so depends on the impact it will have to the external development user community. For example, sublte changes to the Turbine tables have taken place as well as how the access to those tables takes place. Just like the data we have developed in our database for the business logic supported in portlets, the data in the Turbine tables should still be useable after going to 1.4-b3. Turbine no longer supports connection pooling, the DBConnection type is gone and whenever I see the words "convert your code", my idea of reuseability is out the window including the significant amount of testing that was done within our server side applications. I am not so sure that a wider choice available for connection pooling out weighs the work that needs to be done to get our own code to work on the latest minor point release. If as the change log suggests, that a series of bug fixes were made and a few minor enhancements were done between the minor releases, this of course does not justify bumping up the major point release number. In order to facilitate a decision process I think a few rules should be established that will guide the process of when it is appropriate in the Jetspeed development cycle to incorporate major shifts in the framework code that supports the project. It is unrealistic to think that the Jetspeed developers would even entertain a branch of support for various release levels. Conceivably that sort of thing might be expected in-house for a IT shop to do. But that predisposes with the fact that we desire as many people as possible to engage the latest release for making it better by testing it and reporting flaws. The rules would be used in good judgement by the core developers that vote on the decisions to check into CVS functionality that either falls into a minor vs. a major release category. The guidelines should be well known to the external development community because this helps in their planning and decision making process. As it stands now, I feel 1.4.b1 is very stable and I wish to continue using it to build out the portal. On the other hand I almost feel like I must keep a separate development environment going for 1.4-b3 in parallel in order to keep pace. Maybe my thinking is wrong in this regard though. What I think really drives the process along right now is that desire to build in the latest and greatest capability a new release such as Torque might give us with respect to the database. Unfortunately, the abstractions that a package might have that Jetspeed is build upon does not follow in the traditional sense we have in our head as object oriented programmers. That is, if we change the hidden parts whether that is data or methods, it should not impact our users. In our case, it does impact us at the highest level. But that is for another philosphical discussion. As Jetspeed is used by more and more organizations and it grows in its usefulness and complexity, the guidelines become more important. If we can look at a package like Turbine based on their criteria for point releases, for example if Turbine went from 2.1 to 3.0, we might have a rule that says if this happens and the Jetspeed development team feels it is appropriate to be using the 3.0 level of code, then the rule might dictate that Jetspeed also increment to a major release number from 1.4 to 2.0. Not only would such guidelines aid the external development community, it will also give some structure to the idea of when it is appropriate to integrate other Jakarta projects such as the Velocity/Struts idea floating around. If Jetspeed releases at version 2.0, I know that as a planner and architect that I had better be making plans for another development cycle with our own in-house code if I am ever to take advantage of the new Jetspeed release. As of today, making that decision seems pretty cloudy unless you are extremely close to the code. The tendency is though that we are close to the Jetspeed code but not necessarily close to those other supporting packages. I would appreciate any thoughts or enlightment on this topic. I do not propose this to slow Jetspeed development down, rather my purpose is to make that transition from one level of release to the next less painful. Sincerely, John Wubbel The John Wubbel Consultancy, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
