On Dec 13, 2006, at 5:47 PM, Craig McClanahan wrote:
The 1.0.3 release does not work out of the box for us
because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces
1.1.1.
Is it actually a hard dependency or just what the Maven POM says.
Can't say
that I have actually tried that combination.
It's just what the POM says, but I don't know how to override it. In
1.1.1 MyFaces used the "myfaces" groupId and now they use
"org.apache.myfaces". Because of this Maven doesn't know that my
dependency on MyFaces 1.1.5 should override Shale's dependency on
1.1.1. I thought I saw a way somewhere to work around that, but I
can't find it now. Besides, I really do want to see us get another
release out - hopefully one that can go GA.
One thing that might affect Greg's enthusiasm :-) I'd like to see
us do is
try to position for a GA release of everything except shale-tiles,
either by
marking it with a separate release grade when we ultimately vote,
or by
making it available separately as its own release. I think we can
be ready
to have API stability on everything else in just a short while.
I agree. I don't think the tiles piece should hold up the whole
project from going GA. I want to have a way to promote components to
GA as they are ready. I think I prefer the approach of marking
separate release grades over creating separate releases. It seems
like there's too much to do to roll out a release for each component
to have its own cycle. We already distribute everything as separate
packages, right? It doesn't seem like it would be too hard to apply
a quality label to each package individually.
Longer term, I'd also like us to think of the following strategy
when we do
achieve a 1.0.x GA-graded release:
* Branch the 1.0 codebase at that point
* Start working on 1.1 things on the trunk
* Put new features only into the trunk
* As we fix bugs in the trunk, backport relevant ones to the 1.0
branch
I really like this idea. This is basically the way we're doing it at
work. It was the only way I could think of to be able to apply
emergency patches to a stable codebase without deploying unstable
features.
