On 27 October 2013 18:05, 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. > that's maybe the better choice for the project > > One thing to mention: please, don't use "submodules" because a lot of > > people do not understand to handle them ;-) > > > > uhu at least this is the most misunderstood feature when new colleagues are joining the team ;-) git notes are ok for me but require an extra "git task after an commit" (git notes add -m 'bla' 231a45e64)
