couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [DISCUSS] Simplify active release branches (Was: Re: [DISCUSS] Git workflow)
Date Thu, 25 Apr 2013 22:16:20 GMT
On Thu, Apr 25, 2013 at 3:08 PM, Noah Slater <nslater@apache.org> wrote:
> 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...)

If we are reliable about forward compatibility and breaking changes
with version numbering than we really just need 1.X.Y and 2.X.Y
around, but not 1.2.X and 1.3.X. Yah?

In practice it's identical (keep around as many versions as makes
sense for supporting real users), but the numbering does change.

Mime
View raw message