incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: jira task to decide on Apache Flex version number needed
Date Wed, 18 Jan 2012 21:04:34 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message