Honestly, I think this is the best compromise we can reach. Nice job,
+1 Bruno On 25/05/07, Werner Punz <[EMAIL PROTECTED]> wrote:
+1 to your propsal of the numbering scheme... The Blackdown people use something similar for their JDK Implementations. Manfred Geiler schrieb: > 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 >
