couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <a...@nms.de>
Subject Re: [PROPOSAL] tag our commits
Date Sun, 27 Oct 2013 18:10:03 GMT
On 27 October 2013 18:05, 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.
>

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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message