Versioning

[Jan Lehnardt <ja...@couchone.com>]

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.

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.
>>
>>

Re: Versioning

[Robert Newson <ro...@gmail.com>]

This is how Debian distinguishes between new upstream releases versus
packaging tweaks, I think it's a solid idea.

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.
>
>

Re: Versioning

[Dirkjan Ochtman <di...@ochtman.nl>]

On Thu, Nov 4, 2010 at 13:17, Jan Lehnardt <ja...@couchone.com> wrote:
> 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 extra number seems in line with what other places do, so it seems
alright. I suspect you would handle upgrades to the CouchDBX shell,
the same way, e.g. by increasing the extra version identifier.

FWIW Gentoo uses -r1 instead of -1 which I like a tiny little bit
better, but it's basically a wash.

Cheers,

Dirkjan