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
