On Sun, Oct 27, 2013 at 9:05 PM, Benoit Chesneau <[email protected]> wrote: > On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk <[email protected]> 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. -- ,,,^..^,,,
