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