Whether we do this now or not is debatable, in my mind, but the more I think about it, the more I think we'll need to do
it, and just from a project management perspective, let alone a end user confusion one. Shale has components, Action 2
will have components, and certainly Action 1 has components. If the components need their own release cycle, then the
alternative is to have a three-tier organization, but I think Apache wants to avoid that after Jakarta.
I've been starting to work more on Action 2 (WebWork 2.2.2 has been delayed a day so the release and Apache import
should happen tomorrow), and I'm seeing that Action 2 will have at least the following components:
- Core (WebWork 2)
- Apps
- Legacy
And probably more if we split up WebWork 2 further. WebWork 2 currently handles this by setting up Ivy
"configurations", but leaving the code in one tree. You do have the problem where an infrequently, non-core part of
your project holds up releases, but again, unless we could do a three-tiered (Struts -> Action 2 -> Core, each having
their own releases), that's what we'll have to do. Giving Apps its own subproject, with branches for Action 1, Action
2, and Shale is too complicated, I think.
I'm fine staying the course for now to ensure Action 1.3 gets a GA release soon, but we should resolve this before
Action 2 gets out of Incubator.
Don
Ted Husted wrote:
On 3/21/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
And I didn't mean to discourage you -- in fact I offered to help. :)
My comment was qualified with 'from a release manager perspective'.
Obviously, it's easier to package and verify a release for a single
jar than several of them plus example apps.
If anyone really wanted to keep the separate sub-projects, I think
they would have spoken up by now. Somehow I don't think you're going
to get any opposition, and now that the proposal is on the table, I'd
like to see a decision made one way or the other.
I think the important thing is that we not halt any forward progress.
If someone wants to move forward with another build of one or more of
the Action 1 subprojects, then I would suggest staying the course and
rolling the build.
If no one is eager to start moving things about, I'd suggest an
optimum time to recombine the subprojects would be after each had a GA
release. At least then we would have something out the door, where
more teams could use it. A GA release orf each would also demonstrate
an ongoing need to move things about.
But, again, AFAIC, whoever is ready to do the work is welcome to make
the decision.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
