On May 25, 2007, at 4:31 AM, Manfred Geiler wrote:
Arguments pro 2.x.y:
A20.1. Tomcat does the same. They do not align there container
versions to the spec and nobody complains.
This is an excellent proposal and clearly takes all the factors we
have discussed into account. I would have no hesitation in
supporting this approach.
Since Tomcat's approach has factored into this proposal I would feel
remiss if I did not at least mention one other alternative that is in
use at ASF today by the Geronimo project. I don't necessarily mean
to imply that Geronimo's approach is better than Manfred's proposal
or that it even addresses all the issues our discussion has
identified. But I think that for the sake of consistency across ASF
that there is merit in at least giving it a moment of consideration.
As an implementer of many different Java EE specs[1] the Geronimo
project has contended with this issue of using spec vs. release
version. Adding some further complication is that fact that each
spec is released and maintained independently from each other and
from Geronimo's core application server. The current approach
Geronimo takes is to use *both* version numbers, making the spec
version part of the artifact name, and assigning the release version
independently of the spec version. This topic is frequently
discussed by the Geronimo team. See [2] and [3] below for
background, including some feedback from the Maven team.
For example, using this approach Geronimo has released four versions
of the JavaMail 1.3.1 specification. The pom.xml for the first
version looks like this:
<artifactId>geronimo-javamail_1.3.1_spec</artifactId>
<version>1.0</version>
the second like this, and so on:
<artifactId>geronimo-javamail_1.3.1_spec</artifactId>
<version>1.1</version>
Maven produces jar names like this:
geronimo-javamail_1.3.1_spec-1.0.jar
This approach has not been without its detractors. But it has some
advantages, two of the most important being that for release
management you can account for both spec and release versioning
simultaneously, and users can tell the spec and release version by
looking at the jar. It has also proven to work fine with Maven
(version ranges, dependency resolution, etc), and the Maven team has
been actively working with Geronimo to develop and improve the
tooling to support this approach [4].
Like I said, I don't mean to derail Manfred's excellent proposal
which I think could in fact work better for MyFaces in the end. The
main reason I bring this additional information to light is because
while MyFaces is for all practical purposes an autonomous project I
agree with Manfred that for the sake of consistency we should take
what other ASF projects are doing into consideration.
Best wishes,
Paul
[1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
[2] http://tinyurl.com/3yqmzs
[3] http://tinyurl.com/yqu6cn
[4] http://tinyurl.com/yur73u
