I see a lot of checks like these all over the sdk code, third party
libraries (and our own codebase):
if(FlexVersion.compatibilityVersion < FlexVersion.VERSION_3_0 )
{
...
}
if(FlexVersion.compatibilityVersion < FlexVersion.VERSION_4_0)
{
...
}
and so on...
Moving to a year based version number would most probably break a lot of
such checks. Even resetting would cause these checks to fail. I think
FlexVersion.as should be maintained as such and we just keep incrementing
it - at least for the sake of backwards compatibility.
Om
On Wed, Jan 18, 2012 at 12:22 PM, Chris Martin <windo...@gmail.com> wrote:
> I was thinking of continuity of the version number. That's it. Like
> if we ended up doing a huge revamp/improvement/enhancement/whatever,
> we'd move from version 4.x to version 5.1.
>
> Chris
>
> On Wed, Jan 18, 2012 at 1:14 PM, Rick Winscot <rick.wins...@gmail.com>
> wrote:
> > Continuity of what? There's still a ton of mx in the spark code-base,
> functionality is divided among nearly a dozen version numbers, bugs
> abound...
> >
> > What of this do you want to maintain going forward?
> >
> > --
> > Rick Winscot
> >
> >
> > On Wednesday, January 18, 2012 at 2:50 PM, Rui Silva wrote:
> >
> >> > From: "Alex Harui" <aha...@adobe.com (mailto:aha...@adobe.com)>
> >> > The first release, even if it is
> >> > just approximate parity with Adobe Flex 4.6 would be called "Apache
> Flex
> >> > 2012". Any other release cut this year would be a point release
> >> >
> >>
> >> ("Apache
> >> > Flex 2012.1")
> >> >
> >> > --
> >> > Alex Harui
> >> > Flex SDK Team
> >> > Adobe Systems, Inc.
> >> > http://blogs.adobe.com/aharui
> >> >
> >>
> >>
> >> I'd vote on 4.7. It conveys a stronger idea of continuity.
> >
>
