I agree.  Breaking backwards compatibility between major revisions is why
developers make a distinction between major and minor revisions.There is
nothing inherently wrong with incompatible major revisions.


The problem occurs when...

1) Major revisions are released too frequently (likely due to archetectural
flaws)
AND (perhaps consequently)
2) Nobody is maintaining and back-porting fixes to the older revisions.

These two conditions, together, make a framework unusable for application
developers.
Who really cares if there is a T6 when they have a working application on
T5?  No one is forcing an upgrade of an application's framework, simply
because there is a new version out.  The major reason for upgrade would be
if there were severe bugs, or productivity enhancements.  As long as there
are maintainers fixing the bugs in revision I'm using, most will be happy.

I think the approach being taken with T5 is the correct one... try as hard
as possible to architect the framework correctly up front, so that the
period between major revisions is LONG.  That doesn't mean there will never
be another major...


On Fri, Jun 26, 2009 at 2:40 PM, <kra...@k2d2.org> wrote:

> I saw the following comment on Howard's blog and felt compelled to comment:
> "I just felt the need to reiterate that I don't see there ever being a T6;
> I see a stream of backwards compatible updates to Tapestry 5.1. In fact, I
> think the 5.0 -> 5.1 transition was a little rougher than I'd like for
> future releases."
> "The overall approach in T5 was to eliminate the root issues that caused
> the backwards compatibility problems in earlier Tapestries."
>
> Aside from the fact that there is an admittance to things not going as
> planned in the very first version 5 iteration, Howard, I think you are
> sincerely wrong. For based upon your resolve to never have a version 6, I
> see only two possible outcomes:
>
> a) All innovation on the web stops and we continue using T5
> b) Innovation on the web continues and Tapestry becomes obsolete.
>
> To further my argument, assume that T5 had been developed in 1995 for use
> on the web. Do you really see T5 honed for the web as of 1995 being able to
> seamlessly take on, without change in architecture, the following:
>
> - CSS
> - Javascript evolution
> - Ajax
> - IoC
> - Persistence frameworks
>
> The problem with backwards compatibility is introduced at some point in
> every framework for one of two reasons:
> a) The framework decides to adopt a new architecture to support essentially
> the same end goal and platform for gains in productivity, stability,
> scalability, etc.
> b) The framework is forced to adopt a new architecture to support
> innovation in the marketplace (HTML5, offline storage, desktop-web-apps,
> RIA, osgi/java modules/bundles, language improvements, who-knows-what).
>
> The technology community is accepting of (b) as a necessary side effect of
> rapid innovation. It is far more skeptical of (a). However, companies are
> free to attempt (a) since in a free market, the market decides. Open source
> is not immune to that.
>
> So while I find your goal sincere given the v3 -> v4 -> v5 migration
> history, I see it as neither a realistic nor intelligent goal to pursue. In
> fact, quite the contrary, it dissuades people who are evaluating Tapestry.
> Instead of defending your decision to make T5 with the cloak of eternal
> future compatibility, why don't you admit to your error and move on? A
> little humility would be of great benefit and would complement your
> intellectual prowess, which is self-evident in your works.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Reply via email to