Egregious? That demands and answer and perhaps an apology.
Firstly, try porting and app from Weblogic Portal 8 to Weblogic Portal
9. It has conversion tools, but it's not compatible without up-
conversion. Upconversion doesn't count.
Then think of eclipse and the plugins geared for such.
As to appservers themselves, core platforms have a higher bar for
backwards compatibility and always have than component frameworks.
Databases are also externally compatible only because they conform to
an API they didn't write themselves (SQL92, etc.). I'm not sure about
MySQL, but many SQL databases that have native APIs are not API
compatible between releases when using that native API. And try to
move the files over between databases, and you have to do an export
and an import, because you can't just install an upgrade and have
everything work. As I said, upconversion doesn't count.
We're talking about a component framework, which is highly finicky.
If you update the major versions, it's not unreasonable that existing
components won't work. I mean Howard could have spent a lot of effort
making a bridge or translation system to maintain compatibility (which
is often how total rewrites gain their backwards compatibility... see
windows), but he didn't (clearly) think that was worth his time. Of
course, it's open-source, so you could do it, if you wanted it badly
enough.
Oh, and blah blah blah fork blah blah. You know that part.
Regardless of all of this, at least one major apache project has this
policy too, and that's from 2 minutes on google.http://apr.apache.org/versioning.html
. Major versions mean incompatible releases. That's (in my
experience, except for platforms themselves) often the (non-marketing)
meaning of major versions. A few other examples:
http://www.jmock.org/versioning.html
http://xstream.codehaus.org/versioning.html
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html
http://wiki.eclipse.org/Version_Numbering
... oh, and most unix libraries.
While not absolutely true in all cases, it is most certainly true in
many cases, and is not unreasonable.
Now apologize for your imputation, sir, for you are substantially,
demonstrably incorrect.
Christian.
P.S. Ok, I'm not really that offended, just irritated with how
personal you just made it. I don't like being called out for simple
observations from 15 years in software development.
On 19-Oct-07, at 7:00 AM, kranga wrote:
That is an incredible statement! There have been numerous
discussions on this mailing list on the way T4 was made completely
incompatible since it was going to incorporate the very best and
then T5 was made even more incompatible to incorporate the latest.
This has been a vexing issue with quite a few people and
organizations who invested in T3/T4 based projects.
By way of example, tell me how these products are not compatible
within major releases:
Websphere 4, 5, 6
WebLogic: 8, 9, 10
MySQL: 4, 5
Hibernate: 2, 3
There are some pieces that change and new features are introduced.
But your don't have to do a major rewrite to use the newer version.
As an example, if T5 were T4 + annotations, that would be a
compatible release. But Howard has chosen to rewrite it from the
ground up with no compatiblity concern. Well, thats his prerogative
as this is open-source community driven development. If I want, I
can take the T3 code base and establish my own framework. However,
it also reflects on the popularly or lack of for Tapestry. This
topic has been beaten to death and I don't wish to bring it up
again. However, your point regarding versions was egregious.
----- Original Message ----- From: "Christian Gruber" <[EMAIL PROTECTED]
>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Thursday, October 18, 2007 10:58 AM
Subject: Re: Tapestry 5 Roadmap
I'm not sure where "incompatible releases" comes in. No one
releases 1.0 -> 2.0 compatible releases except O/S vendors.
That's typically what the large version number change means - these
are incompatible. That's not a strike against Tapestry, that's an
industry expectation.
Christian
On 18-Oct-07, at 6:45 AM, kranga wrote:
The question is very relevant. The concern of the project should
be to build out the business functionality using existing tools.
If the tools in question are not yet released and in production,
there is a very legitimate concern that the maintenance of the
tool will become a partial focus. Tapestry may be a compelling
offering technologically, but it has many other factors going
against it - lack of a developer mindshare, incompatible releases
in the past, etc. We have used Tapestry for big projects - but we
are still using T3 since T4 and T5 are completely incompatible.
You cannot push beta software past project stakeholders unless
that beta software is also providing you with competitive
advantage. T5 has some able competitors in Wicket and JSF/
Stripes, etc while still lacking an ajax foundation for instance.
So the competitive advantage is not clear cut.
----- Original Message ----- From: "Alex Shneyderman" <[EMAIL PROTECTED]
>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Thursday, October 18, 2007 3:22 AM
Subject: Re: Tapestry 5 Roadmap
The one question I could not answer without looking ridiculous
was "What
happens to our multi-million dollar project if Howard is hit by
a bus
tomorrow"
I think the question is irrelevant. The question you should be
answering:
Is the current base usable enough to push through on the
project?. A
relevant after-question (if answer to the above is not exactly)
to answer
how easy it is to add the features you are missing if you have
to. And
how easy it is to poke through the tapestry's source-base to fix
bugs that
might exist and you will find during the project's development.
If you can cross off HLS as your dependency then t5 is probably
the best
choice to make from what's available out there :-)
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
