+1, great mediation Manfred.
Cheers,
Zubin.
On 5/25/07, Manfred Geiler <[EMAIL PROTECTED]> wrote:
Hi all,
I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
will try to summarize all of the arguments and collect the pros and
cons once more. The goal is to find a compromise that is acceptable
for all of us. I will try to be as impartial as possible. You will see
I'm no pigheaded person. Not always at least... ;-)
Requisites:
R1. Users (esp. non-community members) must be able to find out the
implemented spec version (JSR) easily.
R2. We must be able to distinguish bugfix releases from feature
releases (with changes or extended API).
Arguments pro 1.2.x:
A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
non-community members.
A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
strange and will confuse people.
A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
2.0.x implementation which will confuse people even more.
A12.4. The JSR-252 MyFaces API lib would get the name
"myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
;-)
A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
doesn't have giant technology changes in its core.
A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
specific MyFaces core release, and should use whatever versions make
the most sense.
A12.7. Free evolution of myfaces-impl is possible, but would come at
a cost of incompatibility with the RI.
Arguments pro 2.x.y:
A20.1. Tomcat does the same. They do not align there container
versions to the spec and nobody complains.
A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
releases with changed or extended API will have a higher minor number.
Releases that only fix bugs will only count up the y number.
A20.3. Aligning the version numbers of core and component libs within
the MyFaces umbrella would be easier.
A20.4. MyFaces API can stay with a version number of 1.2, though.
A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
A20.6. What do we do when there is a major refactoring of MyFaces,
similar to Tomcat 5.0 and 5.5
Ok, here is my compromise proposal, which I hope everyone can live with:
C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
means
<major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
C2. We leave the 1.1.5 branch version numbering. Should there ever be
the need for doing a fix in that branch (security, copyright issues)
we will release a 1.1.6.
C3. Non-core libs will no longer be aligned to Core. Which means that
Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
or 2.0.0 or any appropriate number whenever there are major feature
additions or global refactorings.
All Requistes accomplished?
R1: yes
R2: yes
Arguments?
A12.1. solved
A12.2. solved
A12.3. solved
A12.4. solved
A12.5. solved
A12.6. solved
A12.7. not constricted
A20.1. not solved. Well, MyFaces is not Tomcat...
A20.2. solved
A20.3. not solved, but identified as no longer necessary/desired
A20.4. solved
A20.5. not solved, but if there is a JSF fix we must join all our
influence and convice Ed to call it JSF-1.3 ;-)
A20.6. solved, we could switch to 1.2.5.x
Somebody mentioned that this issue is the most controversial since a
while. Well, I hope this proposal is a good compromise and we/I can
start the release procedure next week.
Regards,
Manfred
