Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kxepal@gmail.com designates
 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9qpCP4X8N0Ax_v3oqmSVmvsxPhQ8GJ8K-goPo=dHQOLGw@mail.gmail.com>
References: 
 <CAJNb-9o4KcUfM83qguNAL8maO--dG6adTzueKr7WNo5s5rn91g@mail.gmail.com>
	<7147589D-AB40-4217-AB3B-EF687879D8E7@apache.org>
	<CADA9kr_FWUhJwyaARrbOizogATGjAAJ2Nj93AC6EgJw9XdPnng@mail.gmail.com>
	<CAJNb-9qpCP4X8N0Ax_v3oqmSVmvsxPhQ8GJ8K-goPo=dHQOLGw@mail.gmail.com>
Date: Sun, 27 Oct 2013 22:36:19 +0400
Message-ID: 
 <CAHdjipLisoayt0HTfD71ZqqZfUhuL4qvP0No8eXJ9hiL+J8uZQ@mail.gmail.com>
Subject: Re: [PROPOSAL] tag our commits
From: Alexander Shorin <kxepal@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=UTF-8

On Sun, Oct 27, 2013 at 9:05 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk <andy@nms.de> wrote:
>
>> +1 for Benoits proposal.
>>
>> Regarding "best practices" or "subprojects" mentioned, I would like to
>> share what we do at work. We have destroyed the master branch from our main
>> applications. Our customer has around 5 bigger releases each year. So we
>> started to create the branches, 2013_april, 2013_july, 2013_september and
>> so on. These are our "main" branches we create feature branches from.
>> Merging is always possible from lower to higher month.
>>
>> So deriving from this scenario (what is surely different from CouchDB's
>> requirements) it "could" be an idea to create three main branches like
>> doc_master, ui_master and core_master in the same repository. On the other
>> hand, I guess most of the contributors to a git based project expect to
>> have a master branch.
>>
>
> mmm would work if we make different release for each components imo (which
> isn't bad idea - having a version for the doc and the ui - ). If we go for
> this path I would go for a different repo though. no need for submodules
> imo, a script that collect the result of each repo during a formal couchdb
> release would be enough.

This approach looks fine until these components number is small and
you keeps their backward-compatibility well. Otherwise this will
create versions hell and makes users support very hard. A bit
experience from another open source project: Miranda IM/NG. This is
highly configurable multiprotocol IM with rich plugins system, but
Windows-only.

In Miranda IM there was used same version both for core and main
plugins. That was fine for a first sight, but since each module had
his own development history, that created versions mess: some modules
received massive version bump for several minor versions, some were
downgraded (as by version number). Also, this version now was used not
to track modules development history, but to bind them for specific
project release. In other words, plugin may receive minor version bump
while nothing had changed for him. Fake upgrades sometimes makes users
cry.

In Miranda NG project (new fork that keeps alive and rocks) we solved
this problem very nice: all plugins are stored within same repository
as main project itself and while plugins uses their own version
history, main project uses X.Y.Z.revision (it's svn thing) version to
easily figure for what repository state (aka commit) you have issues.
Also, we strongly do recommend to update plugins with core modules to
negotiate any possible problems. This really solves a lot problems
with compatibility and not only.

TL;DR to go on this path there is need to think twice for all possible
problems and how they could be solved with easy (e.g. plugins updater
helps much!).

P.S. s/plugins/submodules/ is you'd like to. I feel that after Rcouch
merge this question will be raised again.

--
,,,^..^,,,