incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <>
Subject Re: jira task to decide on Apache Flex version number needed
Date Wed, 18 Jan 2012 20:10:25 GMT

I mentioned a version reset... this would be in name only. Read on... ( I know you already
know this - but for anyone that doesn't )

The Flex SDK uses which is tied to - a part of the
mx_internal package. There are 200+ hits in Flex SDK v4.5.1 where version checks are used.
As you hinted... making a flat-out version change would not be a trivial issue. In fact, it
really isn't even an option.

The important question to ask is, "why are these version checks even there?" Because of framework
caching, Adobe signed RSLs, .swz deployment, etc... which are no longer a concern! 

Moving forward - it would be in our best interest to _not_ apply bug fixes, features, or functionality
that is version exclusive. Back to the version reset...

We need to leave alone... and all existing version-checks - I agree. However,
this doesn't prevent us from adding an and using that as our forward
facing / release version (e.g. Apache Flex 1.0).

The delivery model for Flex has changed... and so should our mind-set. The code, however,
is still stuck in the past... which means that one of the first orders of business should
be to log a Jira issue for each of these version checks... 'fix' the problem that required
the check... and then remove the check.

Really... with what I've outlined - is there any reason we can't / shouldn't do a reset? 

Rick Winscot

On Wednesday, January 18, 2012 at 1:29 PM, Alex Harui wrote:

> On 1/18/12 10:08 AM, "Nicholas Kwiatkowski" < (>
> > I would expect Adobe to make any patches, security or otherwise, to the
> > Apache codebase and release based on that.
> > 
> That probably won't happen. Adobe has to have a "fork" so it can control
> the source it is working with, and the folks who will make changes to that
> source are not committers to the Apache Flex project at this time. We will
> integrate patches to the Adobe fork into Apache where relevant. I hope that
> two years out we'll have made so many changes the old code so far behind
> that changes may not integrate cleanlyl.
> In a perfect world, there will never be a reason for Adobe to cut another
> release of Flex. But if there is another release, it is more likely to be a
> 4.6.1 instead of a 4.7.
> I was going to propose going with years "Apache Flex 2012.0" but now I think
> FlashBuilder may be doing that which could cause confusion. I will try to
> find out for sure. I don't think we can go back to 1.0 because of the
> version checking scheme already in there.
> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.

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