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: FLEX-1: graduate Flex!
Date Wed, 18 Jan 2012 15:48:16 GMT
I read the original discussion very carefully... maybe I missed something? 

It seemed to me that most of the comments were logistical, aesthetic, and posturing in nature.
I don't recall anyone taking the issue to people like Matt C., Deepa S., etc for consideration.
Minimally, this should be taken up with the original architects to ensure that we are taking
the 'right' step forward. 

So... this time around, I'm asking the PPMC to consider this from an architectural perspective;
to seek the advice of the original architects and to evaluate the architectural opportunity
cost ( pros / cons ) of making a namespace change at this point.

I've had some very unsavory experience with RSLs and how Flash _cannot_ discriminate clearly
between two classes present in bytecode (whichever loads first is used from that point on).
The only way to guarantee that you are executing the intended bytecode is to make sure that
potential conflicts are not and cannot be loaded. 'Backward compatibility' is a two-edged

Rick Winscot

On Wednesday, January 18, 2012 at 8:13 AM, Nicholas Kwiatkowski wrote:

> On Wed, Jan 18, 2012 at 4:44 AM, Rick Winscot <rick.winscot@gmail.com (mailto:rick.winscot@gmail.com)>wrote:
> > Flex Release
> > # package names... if anyone has worked 'around' the SDK and ended up
> > monkey patching components they'll know what I'm talking about; if we
> > keep the existing namespaces - the collisions, conflicts, and
> > framework caching issues could stall progress (in a bad way). If we
> > change the package structure... it will minimize conflicts and give us
> > a clear path (identity) forward without having to worry about
> > intermingling bytecode ( wink wink ).
> > 
> > Also... this would be a first / relatively easy change that would
> > warrant a first release - establishing the Apache Flex Framework.
> > 
> Lets not bring this up again -- it's already been discussed ad-nausea in
> the past. We don't want to change the package names for 4.6.1. It would
> break ALL the compatibility with previous versions for very little gain.
> Anybody who has written a component that extends ANY component would need
> to update it to work with the Apache Flex. Every example, book, blog post
> out there would no longer be valid -- and that would hurt us in the end.
> Maybe much further down the road this is something we should consider, but
> for right now, lets put out a release with bug fixes and critical updates
> to show we know how to push things forward rather than cosmetic changes...
> -Nick
> > 
> > R
> > 
> > 
> > On Wed, Jan 18, 2012 at 3:52 AM, Bertrand Delacretaz
> > <bdelacretaz@apache.org (mailto:bdelacretaz@apache.org)> wrote:
> > > ...not immediately - but I've created
> > > https://issues.apache.org/jira/browse/FLEX-1 to keep track of the
> > > major steps towards graduation.
> > > 
> > > There's a discussion in the Incubator PMC currently about how to
> > > better keep track of podlings' status and help the move forward, I
> > > think this will help.
> > > 
> > > -Bertrand 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message