sounds good... and the 4-number version mirrors somewhat the RI, they are at 1.2_04P02
so +1 (non-binding from me) > A20.1. not solved. Well, MyFaces is not Tomcat... It is something confusing with Tomcat... one has to search the ewb to know which servlet-spec correlates to which tomcat... so MyFaces improves in this area! > 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 ;-) I would say a bug-fix release of the spec is not important enough to be reflected into the version number of MyFaces. If necessary it will prompt a new impl-minor number to comply... And the discussion about the spec-version usually is held on ##jsf. And some MyFaces-fans are there present. Bruno and Wendy, every now and then show up... and I'm a regular >> 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 ;-) >This only happens if there is a minor release of the spec .... do we >have seen something in the past? No, but it has been discussed already once. ;) An argument for having bug-versions of the spec is the deployment in big corporations which are (usually) very change-unfriendly. So developers have more problems to slip in a new version complying to a new minor of the spec than "being forced to apply the version because of identified bugs"... But I would not expect official spec-releases other than the JSF-nextGeneration spec (JSF 2.0 or JSF6, I fear the latter still has its lobby). regards Alexander -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Geiler Sent: Friday, May 25, 2007 10:32 AM To: MyFaces Development Subject: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0) 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-vers ion> 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
