What's In A Number?

We are getting very close to the public code drop of GoGoEgo Open Source 1.1 and the opening of our early access program for GoGoEgo Commerce integrators.  We're wrapping up the 1.1 code freeze and I look forward to branching the Google Code project as soon as I get a chance to review the snapshot.

I was asked recently, in conjunction with this, what to expect from version numbering in GoGoEgo.  I've posted it before elsewhere, but here are the general rules:

• Major versions (1.x, 2.x) may diverge in very significant ways from each other, and are expected to have only limited portability.
  • No major (2.0) version of GoGoEgo is currently on the roadmap, although we hope to change that in a long range planning session soon.
• Minor versions (1.0, 1.1, 1.2) are expected to be mostly compatible and architecturally similar, but may introduce some breaking changes.  For example, a site that runs on 1.0 will require some small changes in scripts and templates in order to run on 1.1.  Plugins may also need to be targeted to a specific minor version; a plugin for 1.0 will not necessarily run on 1.1.
  • A 1.2 version of GoGoEgo is already well into planning.  Many of the planned features are emerging in the issue tracker at gogoego.googlecode.com.
• Revisions (1.1.1, 1.1.2, 1.1.3) are meant to be transparent and introduce only additive changes or non-breaking bug fixes.  The only exception to this is a critical security problem, exploitable by a non-privileged user, that require a breaking change; we will introduce this category of bug fix in a prompt revision to each actively maintained version, regardless of impact.  Still, revisions should be largely transparent and of interest mainly to project contributors.
  • Revisions happen all the time without much formal planning; it looks, right now, like the first public binary drop of 1.1 will actually be revision number 1.1.4
• You may also see package identifiers or dates appended as a fourth term, e.g. 1.1.1.2009061901 -- but this is significant only to packaging details, the software inside should be the same regardless of the package identifier.

Plugins may have their own version numbering scheme that has nothing to do with GoGoEgo version numbering, but we do recommend the following:

• Follow a hierarchical versioning scheme similar to the one above -- which in turn echoes the practices used by GNU, Eclipse, and Debian -- don't change major versions every time you update the plugin with a new feature.
• Use a major version number of 0 (e.g. 0.1.1) for a plug-in that is experimental or in a state of rapid flux.
• Make sure to use the manifest to state which GoGoEgo API minimum version your plugin requires.  But, don't specify a maximum version unless you know for a fact that a later version of GoGoEgo won't work.

I'll cross-post this information in the Google Group and Help Desk Forum so it's easy to find in the future.