Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of omuppi1@gmail.com designates
 209.85.215.47 as permitted sender)
MIME-Version: 1.0
Sender: omuppi1@gmail.com
In-Reply-To: 
 <CALorpXfYTZcSVxgvrXA-iz4i=9hxc-Mr6S5RM2G8FtFPnJpfBw@mail.gmail.com>
References: 
 <CAEFz_vvFmpUrF8jZsfymqvo9gupESzyauK50FBYSXJpVeXZ4AQ@mail.gmail.com>
 <4F1C21A2.9050504@dot-com-it.com>
 <CALorpXexH05F_maXYZ9giKyftVHojM6JyOdQrG7NeyK0YRRjcA@mail.gmail.com>
 <CAAd0WrankmcaOfTiqyZJNtvhTsbYONLhjFho1LKwLhOEO1+A5w@mail.gmail.com>
 <CAH=GR+FoDHPrdYjeNzDSQLqHC=Onrx4zmgwK4aZ59uqPQzG=bw@mail.gmail.com>
 <20120122101154.14311ywgnns9l8hm@www.teotigraphix.com>
 <CAK1VXSoMRdPYX2Mka4LjZYJaVPh+nKA+=L1ObOTtJv3VxDqBiA@mail.gmail.com>
 <CAH12+xM9tvhcUOZG_uuOCL8CWFx+hhD4hmV+xbMCD+aZ7sWm6w@mail.gmail.com>
 <CAEFz_vs-pOGNud9+N6jLCj0siFUCCXjku_Fe0=1_OoQ9anwwtw@mail.gmail.com>
 <CALorpXfYTZcSVxgvrXA-iz4i=9hxc-Mr6S5RM2G8FtFPnJpfBw@mail.gmail.com>
From: Om <bigosmallm@gmail.com>
Date: Sun, 22 Jan 2012 12:34:33 -0800
Message-ID: 
 <CACK5iZcephnDS96BawsezNTx4iVGBag_zj9MiGtgq=i=jEVJLQ@mail.gmail.com>
Subject: Re: [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to
 building the SDK (and a question))
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d040169d74d03d604b723d967

--f46d040169d74d03d604b723d967
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d040169d74d03d604b723d967--