couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Westreicher Bakk.techn." <st...@meredrica.org>
Subject Re: [PROPOSAL] tag our commits
Date Sun, 27 Oct 2013 16:49:06 GMT
How about using git notes? Messing up the commit message is a bad idea. 

Jan Lehnardt <jan@apache.org> wrote:
>Let’s not branch out the code just yet :)
>
>But tags are a good idea!
>
>Best
>Jan
>--
>
>On 27 Oct 2013, at 14:19 , 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.
>> 
>> One thing to mention: please, don't use "submodules" because a lot of
>> people do not understand to handle them ;-)
>> 
>> Cheers
>> 
>> Andy
>> 
>> On 27 October 2013 14:58, Jan Lehnardt <jan@apache.org> wrote:
>> 
>>> +1
>>> 
>>> Excuse the bikeshed, I’d prefer lowercase tags.
>>> 
>>> Best
>>> Jan
>>> --
>>> 
>>> On 27 Oct 2013, at 13:28 , Benoit Chesneau <bchesneau@gmail.com>
>wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I would like to propose that we start to tag our commits. The
>reasonning
>>>> behind that is to distinct easily the changes concerning  the doc,
>the ui
>>>> and the core and filter them immediately and force us to make a
>change
>>>> atomic. So I would like to propose that we tag the commit line with
>>>> 
>>>> [DOC]
>>>> [UI]
>>>> [CORE]
>>>> 
>>>> other ? Another way to distinct the changes would also be to have
>all of
>>>> these as subprojects eventually but it may require too much
>changes.
>>>> 
>>>> Thoughts?
>>>> 
>>>> - benoit
>>> 
>>> 
>> 
>> 
>> -- 
>> Andy Wenk
>> Hamburg - Germany
>> RockIt!

-- 
Sent from Kaiten Mail. Please excuse my brevity.

Mime
View raw message