Our developers are going to be a varied group -- so "main development" will look quite different to different developers. In particular, look at: (a) a developer writing a java sdk extension for a new IO connector (b) a developer changing the beam model
I think it's fine for work like (a) to occur on master, but I think things like (b) should happen on a development branch so that we can keep the master branch in a working state. There are going to be a number of large, backwards incompatible, churn-y changes to Runner APIs in the near future. I'd like us to be able to do those in a way that doesn't affect folks who are attempting more surface level contributions. Frances On Thu, Feb 18, 2016 at 8:07 AM, Robert Bradshaw < [email protected]> wrote: > +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 > > >
