flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to building the SDK (and a question))
Date Sun, 22 Jan 2012 14:44:16 GMT
Hey all,

First want to say thanks for the great detailed instructions for building
the SDK source, well done!

I think now we are at a point where we need to make a decision on the
versioning numbers. There are already tweets (and blogs probably) talking
about the source code for the SDK, and because there is no decision on the
versioning I've already seen a couple of different people use different

Before this starts getting confusing to users, and before everyone starts
using the source in the "temp" location, let's make a decision so all the
guides being written and shared are accurate.

Here's what I propose for the versioning scheme:

4.6.x - I really think we need to reserve these numbers for Adobe to patch
the last release they put out. There's bound to be some security hole or
critical bug that pops up and 4.6.0 will need patching.

4.7.0 - This should be the first Apache Flex version. Continuing with the
current scheme would be less confusing to long time Flex users. It also
sends a message of stability, vital in enterprise software. This version
should be pretty much identical to what Adobe donated with 4.6.0.

4.7.x - These versions should apply bug fixes and improvements that do not
introduce API breakages, do not add significant new features, components,
or Spark architecture changes.

5.0.x - This version would be our first real baby. Here we are free to
update, change architectures, add components, etc. This would be where the
real fun begins.

I don't really like the proposal to use years, I prefer continuing with
what we already have going. Like I stated, it feels more stable for the
SDK, and like they say: if it ain't broke, don't fix it!

Thoughts? Do we need a vote for versioning scheme?


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