tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Tapestry 3.1 compatibility with 3.0?
Date Wed, 23 Mar 2005 02:24:12 GMT
Geez Howard.... you ask me to bring it to the dev list, then you blog 
it up rather than discuss here (and misspell my name several times!).

You're getting very hung up on this 4.0 version number thing.... the 
changes you've made already cause 3.0 apps to require refactoring, and 
the improvements are dramatic and make it worth it I think.  But there 
is no need to feel like you have to toss in the kitchen sink just for a 
label "4.0".  What's wrong with Tapestry 5.0 with the peer and smarter 
defaults and all that you mention?  The sooner we get to Tapestry X  
the better anyway :)

	Erik


On Mar 22, 2005, at 8:19 PM, Geoff Longman wrote:

> Howard just blogged that if the numbering is bumped to 4.0 then he
> wants to make even more radical changes. Is this really necessary?
> Seems to me that the current set of features is plenty good without
> adding more.
>
> Geoff
>
>
>
> On Tue, 22 Mar 2005 10:54:36 -0500, Colin Sampaleanu 
> <colinml1@exis.com> wrote:
>> +1 on calling it 4.0. This is what I suggested in a thread a month or
>> two ago. I just don't see how, given the common perception of what a 
>> 3.0
>> to 3.1 release means, that it would be at all appropriate unless the 
>> new
>> code was completely or almost completely backwards compatible, which 
>> is
>> not the case here. I actually don't see what the big deal is about
>> calling it 4.0. It's a major release, with lots of new functionality.
>>
>> Regards,
>> Colin
>>
>> Erik Hatcher wrote:
>>
>>> I've been building a new application from scratch using Tapestry 3.1
>>> built from CVS (I'll refresh it every few days as commits mandate to
>>> stay current).  I've encountered a few things that caused me to 
>>> adjust
>>> my code.  I see some of these items as pretty big barriers for folks
>>> adopting 3.1 sooner rather than later or never.  Pleasantly Howard 
>>> has
>>> made the 3.0 DTD's work just fine, but I've been converting to using
>>> the 3.1-style of specification files in order to learn the new way.
>>>
>>> The big things I've encountered are:
>>>
>>>     - classes extending from BasePage must be made abstract, whereas
>>> this was not the case in 3.0.  The whole abstract thing has been a 
>>> pet
>>> peeve of mine for ages and I try to avoid it by using
>>> setProperty/getProperty instead of making abstract getters/setters.  
>>> I
>>> like that my IDE can allow me to automatically add methods when I add
>>> a new interface, but having the class abstract prevents this and adds
>>> to the run-time error possibilities.
>>>
>>>     - IRequestCycle API has changed so that HttpServletRequest is not
>>> accessible from it.  I understand the reason for the change, but my
>>> apps do leverage that capability in 3.0.
>>>
>>> If we're going to make these types of incompatibilities then 
>>> shouldn't
>>> we call this new version 4.0 instead?
>>>
>>> I have been IM'ing with Howard when I encounter these barriers, and 
>>> he
>>> suggested I bring these items to the dev list.
>>>
>>> What do others feel about how compatible 3.1 should be with 3.0?
>>>
>>>     Erik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message