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 >
