Totally agree. Pretty much comes down to what do we think a user will
want by default like you said.
Will they want a specific tag from a release, the branch for some
long-lived version, or the "latest"?
I think both have merit (I can't really say I see a "stable" master more
frequently than a "latest" master or vice versa). Just need to decide
what we'd like :)
Sumit Mohanty wrote:
Agree that master will serve a purpose. develop may go through bouts of
"being temporarily in bad state" due to live coding.
The question is will a user, wanting to use the latest, prefer
1) the master branch that can get updated upon release (can be a surprise
if you do a git pull)
2) the latest release branch but they need to explicitly move to the newer
releases
IMO, later is better as user controls when they move to newer releases.
Presumably they are using a branch (master or otherwise) because they want
to compile the binaries themselves.
That said, we can look at other projects for typical patterns.
-Sumit
On Wed, Jan 28, 2015 at 12:39 PM, Gour Saha<gs...@hortonworks.com> wrote:
The most common use I have seen for the master branch, is to signify that
it contains the most recent release of the product. The individual release
branches would still be there, like releases/slider-0.60,
releases/slider-0.70, etc. But for anyone who would just need the latest
release would not have to look around to find the latest branch or tag.
They would just checkout master. Very old release branches can be purged
from time to time.
*A typical project lifecycle from branching point of view could be
something like this -*
Development happens in develop branch. There would typically be bunch of
features developed in specific feature branches, and they would be merged
into develop. A release branch is then created off of develop when the code
freeze date for a specific release is reached. From then on typically only
bug fixes are taken into the release branch based on QE find. The develop
branch is open at this point for regular development for next releases,
etc. Once the release branch is stable and free of must fix bugs, it is
ready to be released. All release work is done off of the release branch.
Once the global announcement is made and binaries are released to the world
the master branch is synced with this latest release branch.
This document provides more details and is used by quite a few companies
for internal development -
http://nvie.com/posts/a-successful-git-branching-model/
Thoughts and comments on this strategy?
-Gour
On Wed, Jan 28, 2015 at 10:02 AM, Josh Elser<josh.el...@gmail.com> wrote:
Could also just remove "master" in its current use and s/develop/master/,
leveraging the master branch as the normal place things are implemented.
It really doesn't matter in the end (it's just a name), but, if this is
also signifying a move away from git-flow, it makes more sense to me to
use
"master" instead of "develop".
Sumit Mohanty wrote:
I vote for removing the master branch. This is in the line of what I was
also wondering since we have created branches for 0.60 and 0.70.
Branches
can remain the source of truth for the release and can facilitate minor
releases if needed.
On Wed, Jan 28, 2015 at 8:58 AM, Steve Loughran<ste...@hortonworks.com>
wrote:
The latest release process document is now in svn at
site/trunk/content/developing/releasing.md
It hasn't yet propagated to the HTML view, when it does it will be at
http://slider.incubator.apache.org/developing/releasing.html
I think we've outgrown the git flow release process.
The feature branch seems to work well, but the release process has
everything merged into the branch "master",
- It doesn't handle long-lived release/supported branches
- Merging into master/ can create convoluted dependency graphs,
resulting a commit graph (and hence git commit ID) which is
different
from
what is released.
What are we to do?
I'm wondering if we should get rid of that master/ branch altogether.
Instead we could have some tags which we could move around:
- last_branch_6_stable_release
- last_branch_6_dev_release
- last_branch_7_stable_release
- last_branch_7_dev_release
- last_stable_release
- last_dev_release
If you fetch all tags then check out by tag, you end with whatever
version
we think is "last" on a branch; the stable/dev releases can even cross
branches as something migrates from development to stable
During the release process, instead of doing git merge master work,
we'd
just delete some tags, create the new ones and then push them to the
origin.
Thoughts?
-steve
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or
entity
to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the
reader
of this message is not the intended recipient, you are hereby notified
that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender
immediately
and delete it from your system. Thank You.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
