> On 1. Mar 2019, at 15:26, Robert Newson <rnew...@apache.org> 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.
Best
Jan
—
>
> B.
>
> --
> Robert Samuel Newson
> rnew...@apache.org
>
> 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:
https://neighbourhood.ie/couchdb-support/
