+1 to using master for main development (and most non-ASF projects use
master like this too). Not having master (the default when one clones,
etc.) be at HEAD is often surprising. Tags are easy enough to use when one
wants a stable version.

- Robert


On Wed, Feb 17, 2016 at 11:38 PM, Jean-Baptiste Onofré <[email protected]>
wrote:

> Thanks Henry, I remember now, and Frances posted the link.
>
> I agree: we should use the master branch as dev branch as all other ASF
> projects do.
>
> Regards
> JB
>
>
> On 02/18/2016 08:04 AM, Henry Saputra wrote:
>
>> Actually no, it is a bit different.
>> The concept of develop branch is following the "successful git branching
>> model" blog post [1] that introduce using develop branch as active branch
>> for development and use master as stable branch.
>>
>> I would recommend using master branch instead as default branch to do
>> active development to match other ASF projects.
>>
>> Some projects using develop from origin company, like Twill [2], had also
>> moved to using master as default active branch.
>>
>> Just my 2 cents.
>>
>> Thx.
>>
>> Henry
>>
>>
>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>> [2] http://twill.incubator.apache.org/HowToContribute.html
>>
>> On Wed, Feb 17, 2016 at 10:52 PM, Jean-Baptiste Onofré <[email protected]>
>> wrote:
>>
>> Hi,
>>>
>>> Correct me if I'm wrong, but I'm assuming that develop == master (from a
>>> git perspective).
>>>
>>> I configured Jenkins this way as it's the "regular" naming ;)
>>>
>>> I think Frances said "develop" from a dev perspective. All projects use
>>> master (it's what I'm doing in Falcon, Lens, Karaf, Camel, etc, etc).
>>>
>>> Maybe I'm wrong ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 02/18/2016 06:46 AM, Sandeep Deshmukh wrote:
>>>
>>> Hi All,
>>>>
>>>> I have some comments on the repository structure and most of them are
>>>> wrt
>>>> my experience in another Apache incubating project.
>>>>
>>>>
>>>>      1. Most active projects use *master* as default development branch
>>>> than
>>>>      *develop*.  For example, Flink, Spark, Storm, Samza, Pig, Hive, and
>>>>      Hadoop use master branch.
>>>>      2. Released artifacts are always hosted on downloads page.Maser
>>>> need
>>>> not
>>>>      be the one with production ready state.
>>>>      3. It is quite intuitive to use *master* otherwise new contributors
>>>>      needs to go through documentation to understand process of each
>>>> project.
>>>>      4. Overall, the process becomes simple if *master* is the default
>>>> branch.
>>>>
>>>>
>>>> Another suggestion is related to release with major version change.
>>>> Major
>>>> release twice a year is a lot of burden on the end user if they want to
>>>> upgrade to a newer version. To address this issue, newly added APIs can
>>>> be
>>>> marked as @evolving so that users are aware of possible change in the
>>>> upcoming release but the stable one should be carefully changed.
>>>>
>>>> Regards,
>>>> Sandeep
>>>>
>>>> On Sat, Feb 13, 2016 at 2:34 AM, Frances Perry <[email protected]>
>>>> wrote:
>>>>
>>>> Thanks for all the feedback! Please keep it coming as needed.
>>>>
>>>>>
>>>>> We've gone ahead and created components matching this structure:
>>>>>
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/BEAM/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel
>>>>>
>>>>> We'll work on transition existing state from Google-internal tools into
>>>>> this over the next few weeks.
>>>>>
>>>>>
>>>>> On Fri, Feb 12, 2016 at 7:47 AM, Kenneth Knowles
>>>>> <[email protected]
>>>>>
>>>>>>
>>>>>> wrote:
>>>>>
>>>>> On Thu, Feb 11, 2016 at 8:53 AM, Maximilian Michels <[email protected]>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> As for the /develop branch, I would suggest to
>>>>>>
>>>>>>> make it mandatory to have it in a usable state at all times.
>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>
>>>>>> If breakage is accidentally committed (as will happen) then a CTR
>>>>>>
>>>>>> rollback
>>>>>
>>>>> is a encouraged.
>>>>>>
>>>>>> Kenn
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> [email protected]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to