couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Versioning
Date Thu, 04 Nov 2010 15:02:03 GMT
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 <jan@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.
>
>

Mime
View raw message