I am speaking from my experience (and based on others in the mailing list
who have echoed a similar sentiment). It is very frustrating for an
organization to decide to use a framework and then find it is "legacy" in 6
months. Such is software development (and open source) and developers and
corporations take that into account when putting their resources in. This
shows in the lack of Tapestry adoption. And btw native database apis don't
change. Oracle for e.g. has a huge backward compatiblity legacy. There are
changes in most software, but not a complete rewrite.
----- Original Message -----
From: "Christian Gruber" <[EMAIL PROTECTED]>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Friday, October 19, 2007 11:52 AM
Subject: Re: Tapestry 5 Roadmap
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
