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 <f...@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 >> <nicho...@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.develo...@gmail.com>wrote: >>> >>>> On Sunday, January 22, 2012, David Buhler <davidbuh...@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 >>>> >>> >
