Platform 2.0 Version Number Change Discussion: Keep It, Change It?

To get a large majority to agree on one of the systems is unlikely to happen. Although I think that it is not necessary to adopt any already existing naming system.(Why not use Roman numerals for example!) Especially applications that are rapidly evolving need to prevent confusion and provide easy tracking.
The needs are very different to anything like Office, which sell their product on a physical medium. Hence this is a NO to using the year or a yearly release schedule .

The rapid release schedule seems fitting, but in my opinion it should contain the following elements to allow promoting new features yet silently delivering fully tested updates and fixes in the updater:

Version

Is displayed in the menu and website when downloading.
Changes only if

• Basically the whole source is rewritten
• A new standard has been set or an important milestone is achieved

Feature

Is displayed in the menu and website when downloading.(I think they could be named, but that's a different story.)
It changes with

• A new stable feature is released to the public
• A rather large amount of minor releases has been made

Fix

This number should not appear anywhere except in the platform info bit and in the updater, hence no user is bothered with it.
It is used for

• Bug fixes
• Rearranging UI
• Rewriting/changing a feature
• anything else that isn't a new feature but is released to the public

Build

For developers and testers only and as such never actually appears in the software updater as an update for users. Those who wish to take a leap could download these manually or even through the software updater after having ticked some kind of dev-release box. It is however included in the "PortableAppsPlatform.exe" and the about section. As such any builds can be released and tested with a slightly wider audience. This should allow controlled, but real world testing of pretty much anything that has been improved/changed/added/fixed/removed. It also allows for lots of community-feedback throughout development. I therefore propose the use of dates as build numbers such as:

• YYMMDD
• YYMMDDHH

Since there may be 2 released in a day, but not daily, I would think picking the next day should deal with this scenario.

What sign is used as separator seems irrelevant to me, but fullstops seem to be popular. Out of protest I mixed them up

Version.Feature-Fix Build

Benefits:

• Numbers always increase, as we expect
• Fits in with current releases, all the additional bits are "hidden" away from the users eyes
• Current names like "Beta 5" can be interpreted as the Build or Fix number. Since numbers come before letters, they don't mix causing confusion to the user.
• Skipping to higher than 2.5 or maybe even 3.0 is justifiable since plenty of features have been added since 2.0 as well the code has been rather significantly changed since the first release of 2.0
• Build numbers are always increasing independently of the Version, Feature and Fix and allow easy retracing and more flexibility with changing them as they act simmilar to a unique ID for every release made
• Also allows easy checking if platform is outdated or there is a newer release
• Makes it dead obvious when a new feature is added
• When a build is good enough for the world to use, just increment the numbers appropriately and publish it!
• The "feature creep" can go on, but allows a quick release to be made when a feature is complete

I now shall stop rambling on about this idea and bore you no longer.

John, et al:

If you have not seen it, you may find this proposal for "Semantic Versioning" to be of interest. It's written by Tom Preston-Werner, co-founder of Git-Hub.

http://semver.org/

Regards,
Phil Honstein

For my own work and notes I usually use date but replace the month with single letter (A-L) and the date (if necessary) with single digit as well (0-9, A-U). If more than 1 release a day, then usually another single digit will be enough.

So for example a release today (2011-10-08) will formed as 2011J7 - or 2011J if date is not required - where 2011 is the year, J is the 10th month, and 7 represent the 8th day in the month. The date maybe confusing, so it can be replaced by 1-9,A-V digit, so today will be 2011J8.

I think we should keep it at 2.x because everyone is more familiar with it that way.
But whatever you do, don't do it like Mozilla Firefox!!

Are we (you) still considering pondering about what number to get?

It's simple, get 2.x out of beta finally as 2.x. 'Ordinary' users are supposedly still using 1.x as most don't consider beta's stable. They are growing beards on waiting for an official release for what seems to be turning into years now.
"It's done" and if it needs an update they update.

Having abstract version numbers is just hiding the fact that this would be the official release of 2.

Binary, names, "next", bumping version numbers, whatever.. all 'funny' but eventually people want an official version. Easy to understand. If you wanted a higher number you should have released the menu more often as official. Problems from beta are very minor it seems as it works and has been working since the early beta's. Even other applications get updates and stuff...

1.x actual version
2.x testing,beta,alpha,whatnot version
3.x new version
4.x testing,beta,alpha,whatnot version
...

i say how about PA.c: NXT?

Just came across this, and had to share it:
http://www.theregister.co.uk/2011/11/04/bofh_2011_episode_17/