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
