flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Korngut <ke...@spoon.as>
Subject Re: [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to building the SDK (and a question))
Date Sun, 22 Jan 2012 17:22:44 GMT
+1 for Omar's suggestion.

On Sunday, January 22, 2012, nithya flex <nithya4flex@gmail.com> wrote:
> Hi all,
> I think Omar correct. Lets not confuse with user byrenaming version.
> Because when 2 and 3 version came up it was referred by Adobe flex. When 4
> came up it renamed as flash builder 4. I guess it added confusion. lets
> continue with Omar suggestion. Anyway we are building older versions, it
> should go in incremental order.
> On Sun, Jan 22, 2012 at 8:14 PM, Omar Gonzalez <omarg.developer@gmail.com
>> 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
>> versioning I've already seen a couple of different people use different
>> numbers.
>> 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
>> 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
>> 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
>> 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?
>> -omar

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