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 sword... -- 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 <[email protected] > (mailto:[email protected])>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 > > <[email protected] (mailto:[email protected])> 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
