Flex 4.4.12.7, 4..5.12.XX? Conectado pelo MOTOBLUR™
-----Mensagem Original----- De: Tink <f...@tink.ws> Para: flex-dev@incubator.apache.org Enviado: domingo, 22 de janeiro de 2012 22:09:35 GMT+00:00 Assunto: Re: [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to building the SDK (and a question)) 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 >>> >>
