Scott O'Bryan wrote:
Partially ignore this.. :) Let me clairify now that I understand your
proposal..
I think projects need to be in charge of their own destiny based off of
need/usage.. :) Indeed Trinidad has a 1.0.8 branch and a 1.2.8 branch
which is (mostly) functionally equivalent. But I wouldn't say that you
can take code written for 1.2.8 and use it on 1.0.8. You should be able
to, however, do the opposite. So the rules in Trinidad are that items
added to the 1.0.x branch MUST be added to the equivalent 1.2.x branchin
order to provide a clean upgrade path.
The project should document their policy. It is the job of the PMC and
the community to hold the project to their stated policy.
As for the commons, I think it's largely irrelivant. Commons should be
more stable API and functionality wise (and we should do everything in
our power to ensure this). As such, if Trinidad had a minimum
requirement of myfaces-commons-utils 1.2.2 and Tobago had a minimum
requirement of myfaces-commons-utils 1.2.8, Trinidad should work with
1.2.8 as well. I think on the commons side, we can just release each
branch as needed because, especially starting off, we're going to have
projects which will require a release of commons in order to do their
release. Especially if there are some enhancements.
In the illustration, only the major.minor version of common project
change when the JSF support changes. I agree within a major.minor
version upward compatibility is the goal, which puts an emphasis on
testing. In your example of using Trinidad with the 1.2.8 utils sounds
reasonable because the JSF version support did not change. The rules
around version numbers for the "common" projects need to be defined so
the depend projects know what to expect.
Paul Spencer
Scott
Scott O'Bryan wrote:
Paul, why do the CF versions have to be different. This is no
different (IMO) then what I was talking about except that we could not
FORCE people to backport everything.
I don't see why libraries for older JSF's HAVE to be functionally
equivalent. That is not to say that API's started in 1.2 shouldn't be
upheld in the 2.0 version, but why should the 2.0 libraries only
contain functionality relivent to 1.2.. I think the older branches
could be move back as needed and the only real concern we need to
have, therefore, is for forward compatibility except by exception.
As for JDK, if we support JSF 1.1, we should build off JDK 1.4. If we
support JSF 1.2, then there is no reason NOT to use JDK 1.5. If we
support JSF 2.0, then I think 1.6 is the minimum requirement.
Scott
Paul Spencer wrote:
I am one who is using JSF 1.1 for some applications. This is because
the applications are running software/hardware environments which do
not support JSF 1.2. For applications in environment that will
support JSF 1.2, I use JSF 1.2.
Future JSF version are inevitable, thus a solution must not be
limited to support for JSF 1.1. At some point a support for a JSF
version must be scaled back to bug fixes. Below is a starting point
for a long term solution.
We have several different "customer facing" project (
MyFaces,Tomahawk, Trinidad, Tobago, Orchestra, and Portal Bridge) the
must address this JSF version issue. Most restrict a JSF version to
a Major.Minor version of the project. Tomahawk I know support both
JSF versions in the same project version. If all "customer facing"
projects adopt a "restrict a JSF version to a Major.Minor project
version" paradigm, then we can drop support for a JSF version in the
"common" projects with out holding back functionality in the
"customer facing" project because that functionality can not be
implement in the older JSF implementation.
The illustration below is for one "customer facing" project the is
dependent on one "common" project. When the project started, only
JSF 1.1 was supported. When support for JSF 1.2 was added, the
"common" project was able to support both JSF versions. As
functionality was added and bug fixed, the "common" project was able
to support both JSF versions. Version 1.1/2.3 of the "customer
facing" application are functionally equivalent, but the the "common"
project had to be split off JSF 1.1 into a branch, keep JSF 1.2 and
JSF 2.0 support together.
JSF 1.1 JSF 1.2 JSF 2.0
CF Ver CP Ver CF Ver CP Ver CF Ver CP Ver
-------- ------ ------ ------ ------ ------
1.1.0 1.0.0
1.1.1 1.1.0 1.2.1 1.1.0
1.1.2 1.2.0 1.2.2 1.2.0
1.1.3 1.2.1 1.2.3 1.3.0 2.0.0 1.3.0
1.1.3.1 1.2.2
1.2.4 1.3.1 2.0.1 1.4.0
CF Ver = Version of "customer facing" project
CP Ver = Version of "common" project
Version 1.1.3 and 1.2.3 and 2.0.0 are functionally equivalent, the
older JSF uses a different version of the "common" library.
Version 1.1.3.1 is a bug fix release this has no function equivalent
in the other JSF implementations.
Paul Spencer
Simon Lessard wrote:
Hi all,
I have to agree with Andrew here. One year ago, JEE5 server were still
scarce or underused, thus supporting the maintained two branches
argument,
but now is no longer the case and splitting efforts between two code
bases
doesn't sound most efficient.
Regards
~ Simon
On Fri, Jun 20, 2008 at 11:00 AM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:
JSR 252 (JSF 1.2) was finalized on 2006-05-11
Java 1.5 released 2004-09-30
I don't mind people maintaining JSF 1.1, but I do think that there is
very good cause to have 1.1 moved to branches and the latest JSF
specification as the trunk for each project. Over 2 years is plenty of
time to adopt JSF 1.2. If you choose to stay on an old API, there is
just cause to not have the latest and greatest code available. For
those that wish to stay on and support 1.1 on a branch, that is
perfectly fine, but I think it is time to stop burdening every
developer with supporting legacy code without just cause. Other
technologies support the latest, and I think 2 years is plenty of
notice to users.
My $2 (gas price inflation from cents to dollars)
-Andrew
On Fri, Jun 20, 2008 at 3:14 AM, Mario Ivankovits <[EMAIL PROTECTED]>
wrote:
simon schrieb:
In other words, keeping one line of code makes sense (less
maintenance) even if we lose some JSF1.2/JSF2.0-specific features or
performance boosts.
While I second the rest of your mail, I wont do so with the sentence
above.
We are developers, and, at least in your younger years ;-), you'd
like
to keep up with technology
and use the newest things. And JSF 1.2 is anything else then new
today,
not to speak about JSF 1.1.
In contrast, we spent alot of time to make our JSF 1.1 development
upward compatible.
I don't think that we are responsible to provide a vital community
around a library
which itself depends on a stone old architecture.
So, yes to one line of code, but I'd like to see the bundle
Tomahawk+JSF1.1 frozen.
Anything new should go to a JSF 1.2 native Tomahawk.
And JSF 2.0 release date + (lets say) half year the same should count
for Tomhawk JSF 1.2 then.
Ciao,
Mario
