incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Rowe <scottr...@me.com>
Subject Re: [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to building the SDK (and a question))
Date Sun, 22 Jan 2012 22:58:37 GMT
I really liked the idea of year versioning until I watched another group ship their product
late and version 2004Q4 came out in mid 2005 which looked bad. But  it was either that it
reprint a ton of costly marketing material. Either choice was not a good one...



On Jan 22, 2012, at 5:09 PM, Tink <flex@tink.ws> wrote:

> 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