incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <>
Subject Re: [DISCUSS] ApacheFlex Versioning (was Re: A newbie's guide to building the SDK (and a question))
Date Sun, 22 Jan 2012 17:26:29 GMT
On Sunday, January 22, 2012, David Buhler <> wrote:
> I believe Alex's suggestion for a versioning pattern has the following
> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message