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 >
