Re: Versioning

[Benjamin Young <be...@couchone.com>]

On 11/4/10 11:02 AM, Robert Newson wrote:
> This is how Debian distinguishes between new upstream releases versus
> packaging tweaks, I think it's a solid idea.

+1 for Debian style package names.

Here's their in depth write-up:
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

> B.
>
> On Thu, Nov 4, 2010 at 8:17 AM, Jan Lehnardt<ja...@couchone.com>  wrote:
>> 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
>> denoted?
>>
>> Is the extra number confusing? Is any other scheme confusing?
>> Is the matching CouchDB release numbers important enough to
>> keep?
>>
>> --
>>
>> The larger question here is how do we version CouchOne platform
>> releases?
>>
>> 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?
>>
>> Cheers
>> Jan
>> --
>> http://couchone.com/
>> Your Data. Anywhere.
>>
>>