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
>>>
>>
|