couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Versioning
Date Thu, 04 Nov 2010 12:17:36 GMT
Hi all,

Potential Bikeshed alert.


This comes from working on CouchDBX, but is equally valid for
the CouchOne platform.

For CouchDBX I started out naming releases according to their
CouchDB release number (e.g. CouchDBX-1.0.1). So people know
what applies to them when looking for docs or asking for help.

Occasionally, I'd get something wrong during packaging that
would only come up after an initial release. To be able to
distinguish between those releases I introduced yet another
version number (CouchDBX-1.0.1-1, CouchDBX-1.0.1-2, etc.).

Now my question is if that's a good enough way to version
things. How e.g. would upgrades to the CouchDBX shell be

Is the extra number confusing? Is any other scheme confusing?
Is the matching CouchDB release numbers important enough to


The larger question here is how do we version CouchOne platform

The primary objective of version numbers is so users know what
they get. I'm not a huge fan of using version numbers for
marketing reasons, but we may get to that point so we should
maybe think about maintaining an internal set of engineering
version numbers and an external set of marketing version numbers
even though in the beginning they are likely the same.

I believe we want to be able to roll releases for all platforms
with unified version numbers (1.1.0) but individual patch levels
(like I do for CouchDBX) in case we fuck up packaging for a
single platform, so we can release bugfixes there without having
to roll the entire platform.

We should nails this while we're small as our distributions will
only grow, and fast.

Am I overthinking this?


What are your experiences using or creating software versions
that we could learn from?

Your Data. Anywhere.

View raw message