incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <cfram...@adobe.com>
Subject Re: jira task to decide on Apache Flex version number needed
Date Wed, 18 Jan 2012 21:57:41 GMT
This is essential what we were doing here at Adobe.  We had a 4.y branch
and a trunk branch which was 5.0.  The gotcha is that you have to keep
merging all bug fixes from the 4.y branch to trunk (or at least determine
the code changed and a merge isn't needed).

Carol

On 1/18/12 4 :04PM, "Rick Winscot" <rick.winscot@gmail.com> wrote:

>I'm on board Omar... that sounds like a good path forward. Not that my
>vote counts... ;-)
>
>-- 
>Rick Winscot
>
>
>On Wednesday, January 18, 2012 at 3:44 PM, Omar Gonzalez wrote:
>
>> On Wed, Jan 18, 2012 at 12:37 PM, Doug McCune <doug@dougmccune.com
>>(mailto:doug@dougmccune.com)> wrote:
>> 
>> > > 
>> > > If we include bug
>> > > fixes or new features then maybe not.
>> > > 
>> > 
>> > 
>> > 
>> > One of the reasons for people being optimistic about the move to
>>Apache is
>> > the opportunity for bugs that people couldn't get Adobe to fix to get
>> > fixed. To show progress and momentum I'd urge you all to try to fix
>>some
>> > bugs and get releases out there that people can just drop in, so
>>they'll
>> > say "Finally, bug XYZ is fixed, thank god this moved to Apache, I see
>>the
>> > benefit...". If you force everyone to rewrite their apps using the new
>> > packages throughout you're going to lose those people from your cause.
>> > 
>> 
>> 
>> This is why I think we should start with two version branches.
>> 
>> An Apache 4.7.0 branch would be our first release, and should be
>>identical
>> (as close as the donated code allows) to the final Adobe Flex 4.6.0
>> release. In Apache Flex 4.7.0 we would make all those kinds of bug
>>fixes of
>> things we've all wanted fix that Adobe always Deferred on.
>> 
>> An Apache 5.0.0 branch would let us hack into the SDK more freely. This
>>is
>> where we would introduce new components, change the architecture, remove
>> version checks, etc etc and move with more freedom of legacy. This would
>> allow us to make decisions like do we want to drop all the Flex 3 and
>>Flex
>> 4 baggage and only support the new stuff in 5+, etc. I'm in favor of a 5
>> over an Apache Flex 1, even though we'd be free of legacy, just for the
>> sake of conveying the maturity and stability of the framework.
>> 
>> -omar 
>


Mime
View raw message