On 01/04/2013 10:33 AM, Kathy Lussier wrote:
I disagree that there is a perception that Evergreen is stagnating
because we're still at 2.x, but if the problem is that we really should
be at 3.0 or 4.0 because of the big changes that have come with recent
releases, then maybe the solution is that we start following the
guidelines in http://www.open-ils.org/dokuwiki/doku.php?id=versioning.
Kathy
Hello,
It is amazing that a community can spend so much time on something
presumably simple as version numbers and what they mean. My two primary
communities are PostgreSQL and Python, by far PostgreSQL and our current
version is 9.2.2.
9.2 is the major version, .2 is the bugfix/patchlevel/service pack level.
Once we release a major version, the only code that is pushed into the
branch is bug fixes, no features or anything that doesn't fix a problem
that has been found.
In the past we have also had the version number argument. We have found
that the most sane way to do it is the way it is done. Which means we
may be in the 9.x series for a very long time. This certainly hasn't
hurt PostgreSQL's popularity.
The question is, when do we bump out of a major series to the next, say
7 to 8 or 8 to 9. Each of these jumps were done because of very specific
reasons. When we went from 7 to 8, it was because we had native Windows
support. When we went from 8 to 9 it is because we had native
replication/hot standby support.
Version numbers are definitely something lands lends to marketing and
advocacy. If it is not a major version update, people question if it is
a needed update and what they will get from the update. Any version
numbering change should be consistent with the goals of the project. If
the project wants to project the stability of a release, keep it within
the same numbering scheme as the previous release. If they want to
promote the new whiz bang features, then it should jump in a manner
consistent with advocating the features now available.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579
