couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Maintainig two codebases
Date Fri, 01 Mar 2019 14:36:13 GMT

> On 1. Mar 2019, at 15:26, Robert Newson <> wrote:
> Hi,
> The first decision is to what extent we are supporting the "old" version (once the new
one exists, of course). I think it would be limited to security fixes.

Eventually yes, but I can imagine a grace period for bugfix release before go to security-only.
Reality might not require it, but I don’t want to close the door on this just yet. Either
way tho, this doesn’t change the discussion at hand.

> If so, this is exactly the same as when we released 1.2, 1.3, and so on. Master is always
latest (FDB, in this case) and there are branches like 1.2.x or 2.0.x if we need to backport
security fixes to make a release there.

One special case is that we are now effectively doing 3.0 and 4.0 in parallel for a bit until
3.0 is out. We just need to decide which version stays in-branch until 3.x is out. I don’t
think there is a clear winner either way.

To deal with the PR awkwardness, we could fork current master into a new repo, make that FDB
CouchDB, and when 3.x ships and gets its 3.x.x branch we merge the other repo back as master,
maybe via a special case where FDB CouchDB master straight out replaces then current couchdb.git
master, and that master is moved to 3.x.x. Will need some ASF Infra help obvs. I would want
to avoid having to merge things back and forth for anything that isn’t kept around (chttpd,
replicator, etc), as nice as Nebraska is, I wouldn’t want to put anyone through a big merge
bonanza again.


> B.
> -- 
>  Robert Samuel Newson
> On Fri, 1 Mar 2019, at 13:49, Ilya Khlopotov wrote:
>> There are ongoing discussions about rebasing CouchDB on top of 
>> FoundationDB. It seems like the community is in agreement that it is 
>> worth it to try. This would mean that we would be supporting and 
>> extending two quite separate codebases. How are we going to do it? 
>> Possible options are:
>> - brand new repository
>> - separate branch which we would treat as master for FDB rebase project
>> I think that separate branch approach has a number of disadvantages:
>> - CI might require different dependencies
>> - It would be awkward to open GH issues since we would have to always 
>> refer to the project we are talking about
>> - There would be little friction when we open PR since the correct base 
>> branch would need to be selected
>> Best regards,
>> iilyak

Professional Support for Apache CouchDB:

View raw message