couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject [DISCUSS] Simplify active release branches (Was: Re: [DISCUSS] Git workflow)
Date Thu, 25 Apr 2013 22:08:35 GMT
Splitting this off to let the Git conversation continue
without interruption.


On 25 April 2013 22:54, Dale Harvey <dale@arandomurl.com> wrote:

> The Roadmap looks good, I would worry that the point of semver is that you
>  dont need to support 1.0.X / 1.1.X / 1.2.X and 1.3.X as they are all
> guaranteed to be forward compatible and extended support / backports are
> for backporting bugfixes to major version changes, the release procedure
> is a slow process and it seems like having 4 active versions is also
> confusing for users, but my experience may be differing requirements.
>

Hmm. Interesting point. I am open to revising this.

My main question would be: is there any instance in which somebody might
reasonably _not_ want to upgrade from 1.2.x to 1.3.x? If the answer is
"yes", then we need to keep that 1.2.x branch around to backport bugfixes
to. If the answer is "no" then I think we can probably simplify our roadmap
process / calendar quite a bit...

I would also be curios under what situation you would ever release a bugfix
for a minor point release that wasn't the active release. i.e. Let's say
you release 1.2.0, and then 1.3.0 a week later. And let's say you found a
bug in both. Would you just release 1.3.1, and the 1.2.0 line is considered
inactive?

I know that semver promises forward compatibility between minor point
releases, but something in my mind is niggling at me and telling me there
may be a legitimate reason to keep old point releases around for bugfixes...

(But I would _love_ to simplify this...)

-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message