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