incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tink <f...@tink.ws >
Subject Re: [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to building the SDK (and a question))
Date Sun, 22 Jan 2012 22:09:01 GMT
I'd rather go with Omar's proposal that year versioning. Maybe a vote  
thread should be started?

Tink

On 22 Jan 2012, at 20:34, Om wrote:

> Right!   And as we discussed earlier, the current version number is  
> stored
> as an 'uint' in FlexVersion.as.  If we switch to the year based  
> system, we
> need to switch it to a Number or a String.  This might cause version  
> checks
> (there is no way we can get around version checks IMHO) to break  
> badly.
>
> Overall, I agree with Omar's proposal.
>
> Regards,
> Om
>
> On Sun, Jan 22, 2012 at 11:24 AM, Nicholas Kwiatkowski <nicholas@spoon.as 
> >wrote:
>
>> I personally would like to keep the current version number system  
>> rather
>> than years.
>>
>> You keep major version numbers where you expect major updates,  
>> overhauls,
>> or breakage.  Minor version numbers are for fixes or small updates  
>> only --
>> no major changes.
>>
>> When I look at Ubuntu (which is the first software that comes into  
>> my head
>> as far as year-versioning), I have no expectations as to what version
>> 2010.01 does vs. 2010.03.   I happen to know that even though 2010.03
>> "looks" like a point release, it was a HUGE change, where they  
>> changed the
>> default file system, default window manager, etc., and along the  
>> way broke
>> everything in sight.   Versus RedHat's numbering system where you  
>> have a
>> disctict v3.x or 4.x to make things very obvious.
>>
>> When we are working with enterprises, we need to re-assure them  
>> that we
>> won't break everything on every release.  Having major/minor version
>> numbers helps quell that worry. Heck, some companies use even/odd  
>> release
>> numbers to signify additional stuff, for example long-term support
>> schedules...  Juniper, for example has code releases where
>> certain predictable release numbers are classified as "long-term  
>> support"
>> where they will continue to do patches, etc for a minimum of 5  
>> years, vs. 2
>> years for that trunk, even though it may not be the latest and  
>> greatest
>> version any more...
>>
>> -Nick
>>
>> On Sun, Jan 22, 2012 at 12:26 PM, Omar Gonzalez
>> <omarg.developer@gmail.com>wrote:
>>
>>> On Sunday, January 22, 2012, David Buhler <davidbuhler@gmail.com>  
>>> wrote:
>>>> I believe Alex's suggestion for a versioning pattern has the  
>>>> following
>>> benefits:
>>>>
>>>> 1) The versioning pattern separates Adobe's SDK Versioning from the
>>>> Apache SDK Versioning. This provides a simple visual cue about SDKs
>>>> the community has developed vs SDKs Adobe has developed.
>>>
>>> It will be distinguishable regardless of version scheme because it  
>>> will
>> a.)
>>> have a new logo and b.) have the new name: Apache Flex.
>>>
>>>
>>>> 2) Using a year in a versioning pattern is a way to show the  
>>>> speed of
>>>> releases over a one year timeframe.
>>>
>>> It will also show how many releases you DIDN'T do in a year...  
>>> that said,
>>> does it matter how many per year? Firefox releases 20 version a  
>>> year now
>>> (exaggeration) and their browser still sucks.
>>>
>>>
>>>> 3) Using a year in a versioning pattern allows for quick numerical
>>>> sorting when looking for an SDK.
>>>
>>> How is that any different from sequential version numbers? I don't
>> believe
>>> it's any different.
>>>
>>>> 4) Using a year in a versioning pattern provides a simple frame of
>>>> reference to remember what a particular SDK included (or, read  
>>>> another
>>>> way, what someone invested into a particular SDK).
>>>
>>> Don't see how the year 2011 let's me know that Spark bugs were  
>>> fixed in
>>> releases of that year.
>>>
>>> This make it easier
>>>> to remember a timeline of a particular feature's evolution. People
>>>> relate to dates they can associate with periods in their life much
>>>> better than version numbers, since version numbers have no  
>>>> association
>>>> with life-events.
>>>
>>> Better yet, release notes, README files and change logs are much  
>>> more
>>> efficient at portraying the evolution of software as opposed to  
>>> trying to
>>> remember feature sets from memory using year based numbering  
>>> systems.
>>>
>>>
>>> -omar
>>>
>>


Mime
View raw message