On Fri, March 17, 2006 1:48 pm, Don Brown said: > I might as well make this its own proposal: I propose we consolidate the > 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' > subproject. We would keep the extensions as separate, but include them in > the 'action' subproject meaning they will continue to share the same > version > number and release cycle.
Just to see if I understand... There would be a single "Action" entity, that contains all of these? If you download "Action" you get extras and el and taglibs, etc.? In other words, what has been the case for some time would still be the case, except that we call the entity "Action" as opposed to "Struts". Is that correct? If so, definite +1 from me. > The reason I propose this is while the original feeling was these > extensions > would develop lives of their own and not hold up releases, the opposite > has > proven true, especially now with Action 2 coming down the pipeline. The > same people that update tablibs, for example, are the same people that > work > on Action 1, and there just hasn't been a clamoring need to release a new > version of tabligs without a new version of Action. By consolidating, we > stave off user confusion and simply the work of the Struts developer. If I'm understanding your proposal, it would be a course change, but I think a very good one. I recall there being a fair bit of concern raised when the decision was originally made... if some of those concerns have come to fruition, quite possibly because other things happened in the intervening time (was the WW merger on the table when this was decided for instance?) then reversing the decision makes sense. > I'd imagine this organization would allow the build for these > action-related > extensions to try to build each other, leaving the other subprojects to > use > snapshots instead. If every subproject had its own release cycle, I > wouldn't think we'd need/want a build that built each from trunk, since > each > subproject would require different minimum versions of each other > subproject. For example, Scripting might require only Struts 1.1, so it > wouldn't make since for its build to try to build Action 1 from trunk. On > the other hand, building 'extras' would force a 'core' build. I think this proposal would eliminate a lot of potential confusion with version dependencies, which I think is clearly a good thing. > As far as impact, I'd like to hear from the build folks (Wendy) if this > would seriously impact the build. If so, we could hold off, but I really > think this is the direction we need to move. I know it seems like we are > going backwards, but I see it as simplying our project and better aligning > it with the current energies and direction of its developers. I wouldn't consider it a step backward actually... an idea was proposed... it was implemented... there is now some thought that maybe it didn't work out quite as hoped... now a decision is made to do something different which just happens to be what was done before the decision. This is just good, flexible, thoughtful decision-making and leadership. I can only speak as a member of the developer community... I thought the separate release cycles, while not without merit, had the potential to be confusing and make things more difficult on developers, and maybe too the committers. Therefore, I would support this proposal, just as an interested third-party. > Don Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
