[git/modularization] Suggested names for branches?
At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library. Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names. The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master). Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches. To try to avoid an extended bicycle shed discussion, perhaps people could mention names they have actually seen used and know worked well. --Beman
Le 04/06/12 03:18, Beman Dawes a écrit :
At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library.
Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names.
The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master).
Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches.
To try to avoid an extended bicycle shed discussion, perhaps people could mention names they have actually seen used and know worked well.
Hi, I would expect to have a branch for each release and hotfix instead of all the releases sharing the same branch. At work I'm used to have a main branch, one feature branche by feature and one release branch by release. This has the advantage of not needing the merge from develop to master and discovering that you can not merge because you depend on other parts that are not merged yet. Which are the advantages of maintaining two parallel branches as develop and release? Why do we need to test two branches every time? I will expect that the main/trunk branch is tested every time and that each release branch is tested as soon as it is created and until it is released. Developers needing to integrate their work could create an integration branch and why not they could request some testers to add this integration branch to be tested until it is merged to the main branch. I recognize that this model could mean some more work for testers, but if with Git it is so simple to create branches and merge from them, I don't see why we should work with fixed branches. Just my 2cts, Vicente
On Mon, Jun 4, 2012 at 2:39 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I would expect to have a branch for each release
I think the issue is discover-ability. In a modularized Boost, each library will have its own repo and release cycle. So the question becomes what is the current release for this library? If the current release is simply the head of the "release" branch, that's easy to answer both for humans and for automated processes.
and hotfix instead of all the releases sharing the same branch. At work I'm used to have a main branch, one feature branche by feature and one release branch by release. This has the advantage of not needing the merge from develop to master and discovering that you can not merge because you depend on other parts that are not merged yet.
Hotfix and feature branches are local project workflow decisions, so their existence and names are up to that library's maintainer. The main development branch (i.e. what we currently call trunk) should probably also be easily discoverable by humans for uses like looking at development logs. Maybe also by automated processes, although I'm less sure of that. So its name should also be common to all boost projects. Seems like "master" is the traditional git name for this branch, but I'll defer to git experts on this one.
Which are the advantages of maintaining two parallel branches as develop and release? Why do we need to test two branches every time?
The public repo needs a release branch at the minimum. For a really tiny library, I suppose a maintainer might do all work locally on that branch and then push to the public repo. But that would be poor development practice for real-world libraries.
I will expect that the main/trunk branch is tested every time and that each release branch is tested as soon as it is created and until it is released.
There are two cases; monolithic testing like we do now, and a future continuous integration test environment. Monolithic testing would presumably still be based on trunk (under a new name) and release branches. Continuous integration testing will be a different animal and we don't know the full details yet. But the development branch / release branch / various other ad hoc branches model is in use with numerous CI schemes for other projects, so is known to work in those environments. --Beman
on Mon Jun 04 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Mon, Jun 4, 2012 at 2:39 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I would expect to have a branch for each release
I think the issue is discover-ability. In a modularized Boost, each library will have its own repo and release cycle. So the question becomes what is the current release for this library?
If the current release is simply the head of the "release" branch, that's easy to answer both for humans and for automated processes.
Good point.
and hotfix instead of all the releases sharing the same branch. At work I'm used to have a main branch, one feature branche by feature and one release branch by release. This has the advantage of not needing the merge from develop to master and discovering that you can not merge because you depend on other parts that are not merged yet.
Hotfix and feature branches are local project workflow decisions, so their existence and names are up to that library's maintainer.
True, but I'd like to discourage that if possible. Discoverability is still desirable, even at that level, and is helped by uniformity. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Beman Dawes wrote
On Mon, Jun 4, 2012 at 2:39 AM, Vicente J. Botet Escriba <vicente.botet@> wrote:
I would expect to have a branch for each release
I think the issue is discover-ability. In a modularized Boost, each library will have its own repo and release cycle. So the question becomes what is the current release for this library?
If the current release is simply the head of the "release" branch, that's easy to answer both for humans and for automated processes.
If we decide to have only one release branch, the head of this release branch will not be IMO the last public release. I guess that this information belongs IMHO to documentation and tools must be configured to take the release that is needed. Taking the last release is not something that always works on modularized repo. Using a single branch will not avoid the integrator of the whole Boost to know about the tag that corresponds to the last public release of each library, isn't it?
and hotfix instead of all the releases sharing the same branch. At work I'm used to have a main branch, one feature branche by feature and one release branch by release. This has the advantage of not needing the merge from develop to master and discovering that you can not merge because you depend on other parts that are not merged yet.
Hotfix and feature branches are local project workflow decisions, so their existence and names are up to that library's maintainer.
What prevent us to have hotfixes for the whole Boost? Feature/Integration branches could be shared between several library authors.
The main development branch (i.e. what we currently call trunk) should probably also be easily discoverable by humans for uses like looking at development logs. Maybe also by automated processes, although I'm less sure of that. So its name should also be common to all boost projects. Seems like "master" is the traditional git name for this branch, but I'll defer to git experts on this one.
I agree with this main/trunk/master branch.
Which are the advantages of maintaining two parallel branches as develop and release? Why do we need to test two branches every time?
The public repo needs a release branch at the minimum. For a really tiny library, I suppose a maintainer might do all work locally on that branch and then push to the public repo. But that would be poor development practice for real-world libraries.
This is my concern. We need a trunk branch and more than a release branch which are created from trunk at the moment the release contents is there.
I will expect that the main/trunk branch is tested every time and that each release branch is tested as soon as it is created and until it is released.
There are two cases; monolithic testing like we do now, and a future continuous integration test environment.
Monolithic testing would presumably still be based on trunk (under a new name) and release branches.
Continuous integration testing will be a different animal and we don't know the full details yet. But the development branch / release branch / various other ad hoc branches model is in use with numerous CI schemes for other projects, so is known to work in those environments.
I know and I work with CI systems and we use several release branches without problems. I'm just saying that we need specific release branches and not only one that forces merge from trunk for each release as we are doing now. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/git-modularization-Suggested-names-for-br... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mon, Jun 04, 2012 at 08:01:48AM -0400, Beman Dawes wrote:
The main development branch (i.e. what we currently call trunk) should probably also be easily discoverable by humans for uses like looking at development logs. Maybe also by automated processes, although I'm less sure of that. So its name should also be common to all boost projects. Seems like "master" is the traditional git name for this branch, but I'll defer to git experts on this one.
My reading of the document is that "master" is what Boost has traditionally called "release", and "develop" is what Boost has traditionally called "trunk". The basic release workflow proposed sounds exactly like the current one: it's a promotion/integration model. As a consumer of Boost libraries, I've frequently found reported bugs "fixed" when they enter the development branch but it's very time consuming to ascertain whether a given bug fix ever made it into a release. Is there any thought how to address this in the new workflow? Regards, -Steve
on Mon Jun 04 2012, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
On Mon, Jun 04, 2012 at 08:01:48AM -0400, Beman Dawes wrote:
The main development branch (i.e. what we currently call trunk) should probably also be easily discoverable by humans for uses like looking at development logs. Maybe also by automated processes, although I'm less sure of that. So its name should also be common to all boost projects. Seems like "master" is the traditional git name for this branch, but I'll defer to git experts on this one.
My reading of the document is that "master" is what Boost has traditionally called "release", and "develop" is what Boost has traditionally called "trunk".
Yes, that's git-flow terminology
The basic release workflow proposed sounds exactly like the current one: it's a promotion/integration model. As a consumer of Boost libraries, I've frequently found reported bugs "fixed" when they enter the development branch but it's very time consuming to ascertain whether a given bug fix ever made it into a release. Is there any thought how to address this in the new workflow?
Well, the difference here is that individual maintainers decide when/how to release their own libraries. A "boost release" will only ever contain some combination of released library versions, but individual maintainers can announce and release a new version of their own libraries at any time. So an individual maintainer will have a personal stake in all kinds of release activities, such as merging features from their integration branch ("develop") and writing release notes. Right now, since it's out of my hands when the world actually sees my changes, I am disincentivized from dealing with my release branch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Jun 05, 2012 at 10:58:25AM -0400, Dave Abrahams wrote:
The basic release workflow proposed sounds exactly like the current one: it's a promotion/integration model. As a consumer of Boost libraries, I've frequently found reported bugs "fixed" when they enter the development branch but it's very time consuming to ascertain whether a given bug fix ever made it into a release. Is there any thought how to address this in the new workflow?
Well, the difference here is that individual maintainers decide when/how to release their own libraries.
So are you saying that the Boost source control model will move from a monolithic promotion model to a a fine-grained promotion model? So each library maintainer is going to push changes from "devel" to "release" on their own? I thought that's what happens now, so I don't see the difference. It's the promotion model itself that is, IMHO, broken. Or at least, I still haven't learned of a good way to handle issue tracking that includes both the state of "fixed in devel" and "fixed in release". The lack of this distinction is a source of frustration from my end. On the other hand, handling this distinction manually would create more procedure for maintainers fixing bugs. There must be an automated solution out there.
A "boost release" will only ever contain some combination of released library versions, but individual maintainers can announce and release a new version of their own libraries at any time.
So how is a boost release created? Are you saying that anytime a library maintainer makes a release, that a new release of Boost is made? Or will boost be broken up into smaller modules with loose coupling between them so that they can release on independent cycles? Thanks, -Steve
on Sat Jun 09 2012, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
On Tue, Jun 05, 2012 at 10:58:25AM -0400, Dave Abrahams wrote:
The basic release workflow proposed sounds exactly like the current one: it's a promotion/integration model. As a consumer of Boost libraries, I've frequently found reported bugs "fixed" when they enter the development branch but it's very time consuming to ascertain whether a given bug fix ever made it into a release. Is there any thought how to address this in the new workflow?
Well, the difference here is that individual maintainers decide when/how to release their own libraries.
So are you saying that the Boost source control model will move from a monolithic promotion model to a a fine-grained promotion model? So each library maintainer is going to push changes from "devel" to "release" on their own?
Sure.
I thought that's what happens now, so I don't see the difference.
One difference is that the project's release branch is never closed. You never need a release manager's permission to make a release.
It's the promotion model itself that is, IMHO, broken. Or at least, I still haven't learned of a good way to handle issue tracking that includes both the state of "fixed in devel" and "fixed in release".
That is an important issue.
The lack of this distinction is a source of frustration from my end. On the other hand, handling this distinction manually would create more procedure for maintainers fixing bugs. There must be an automated solution out there.
A "boost release" will only ever contain some combination of released library versions, but individual maintainers can announce and release a new version of their own libraries at any time.
So how is a boost release created? Are you saying that anytime a library maintainer makes a release, that a new release of Boost is made?
No. A release will be made by Boost release managers on a regular schedule.
Or will boost be broken up into smaller modules with loose coupling between them so that they can release on independent cycles?
That too. A Boost release is a package consisting of a tested combination of released versions of Boost libraries. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Date: Mon, 4 Jun 2012 22:47:50 -0500 From: Steve
On Mon, Jun 04, 2012 at 08:01:48AM -0400, Beman Dawes wrote:>> The main development branch (i.e. what we currently call trunk) should>> probably also be easily discoverable by humans for uses like looking>> at development logs. Maybe also by automated processes, although I'm>> less sure of that. So its name should also be common to all boost>> projects. Seems like "master" is the traditional git name for this>> branch, but I'll defer to git experts on this one. My reading of the document is that "master" is what Boost has> traditionally called "release", and "develop" is what Boost has> traditionally called "trunk". The basic release workflow proposed sounds exactly like the current> one: it's a promotion/integration model. As a consumer of Boost> libraries, I've frequently found reported bugs "fixed" when they enter> the development branch but it's very time consuming to ascertain> whether a given bug fix ever made it into a release. Is there any> thought how to address this in the new workflow?
The git-flow "master" branch contains canonical releases ONLY. Ourcurrent "release" branch is in flux with changes until someone decidesto "ship it," and we make the ZIP (or whatever) files from that tagpoint. The git-flow "master" branch only has those "ship it" points.If we have been using git-flow for Boost's lifetime, it would have only around 60changes, corresponding to our ~60 releases. As you said, we would make our current "trunk" the new "develop" branch.At time of release, we create a temporary "release" branch, instead ofa semi-permanent one. Once we clean up the "release", we copy the "shipit" changes to both the "master" and "develop" branches. Then we killthe "release" branch. Hot fixes work the same way as releases. The difference is that "release"branches are split from "develop" while "hot-fix" is split from "master."After certification, the changes are imported to both permanent branchesand the temporary one is killed. If you didn't know, "master" is the name of the default branch when youcreate a Git repository. It's also the only branch from a remote sitewhen you copy/import/clone it, if there's no public branches added.Since the git-flow master branch is only for canonical releases, regularusers new to Boost will start off with production code! A user thatwants to develop, or see the latest code, has to intentionally switchto the "develop" branch to see the latest code. Whichever of the twopermanent branches s/he uses, s/he can make a hot patch for any problemsand send in a diff to our bug-tracker (or this list). This "master == canonical" will help the Boost developers if we makesubrepositories per library. Each library will use the "develop" and"master" system, along with any (private) feature branches. Remember thatwe can use each other libraries. The situation now is that we all shareeach other's beta code for our dependencies. But I'm proposing that whenone Boost library depends on another, the library just points to thecanonical & stable version on the other's "master" branch! At releasetime, the coordinator merges all the latest master versions to test themfor cross-compatibility (in the "release" branch). After the adjustments,we create a new entry for the entire-Boost "master" and import any changesto each individual "master" branch (unless that library didn't change). Daryle W.
on Mon Jun 04 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 04/06/12 03:18, Beman Dawes a écrit :
At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library.
Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names.
The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master).
Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches.
To try to avoid an extended bicycle shed discussion, perhaps people could mention names they have actually seen used and know worked well.
Hi,
I would expect to have a branch for each release and hotfix instead of all the releases sharing the same branch.
If you read the git-flow docs carefully, you'll see that they don't exactly share a branch in any trivial sense. The system is carefully organized to prevent out-of-control branch proliferation and encourage forward propagation of hotfixes.
At work I'm used to have a main branch,
I think that's what git-flow calls "develop"
one feature branche by feature and one release branch by release. This has the advantage of not needing the merge from develop to master and discovering that you can not merge because you depend on other parts that are not merged yet.
I don't think that has any advantage over the git-flow method, because they're almost identical. The only difference I can see in practice is that later release branches have earlier release branches as parents.
Which are the advantages of maintaining two parallel branches as develop and release?
One obvious advantage: there's a convenient tool and lots of documentation that support this workflow. I'm not sure about technical advantages.
Why do we need to test two branches every time?
What does "every time" mean? It's useful to run feature-integration tests on "develop" continuously. It's useful to test release candidates before they get shipped. I don't think we can live without either one.
I will expect that the main/trunk branch is tested every time
Meaning, on every commit to the main branch
and that each release branch is tested as soon as it is created and until it is released.
Meaning, on every commit to the release branch
Developers needing to integrate their work could create an integration branch
That's what the "develop" branch is.
and why not they could request some testers to add this integration branch to be tested until it is merged to the main branch.
We have plans to support testing requests for specific branches.
I recognize that this model could mean some more work for testers, but if with Git it is so simple to create branches and merge from them, I don't see why we should work with fixed branches.
I think you've misunderstood git-flow. There's nothing particularly "fixed" about the branches; they seem to work very similarly to what you're proposing. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Le 04/06/12 18:26, Dave Abrahams a écrit :
on Mon Jun 04 2012, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr> wrote:
Le 04/06/12 03:18, Beman Dawes a écrit :
At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library.
Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names.
The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master).
Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches.
To try to avoid an extended bicycle shed discussion, perhaps people could mention names they have actually seen used and know worked well.
Hi,
I would expect to have a branch for each release and hotfix instead of all the releases sharing the same branch. If you read the git-flow docs carefully, you'll see that they don't exactly share a branch in any trivial sense. The system is carefully organized to prevent out-of-control branch proliferation and encourage forward propagation of hotfixes. I was responding to Beman post, which is proposing a specific work flow.
I think you've misunderstood git-flow. There's nothing particularly "fixed" about the branches; they seem to work very similarly to what you're proposing.
Again, I don't know git-flow. I just read the link given in the OP. Best, Vicente
on Sun Jun 03 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library.
Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names.
The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master).
Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches.
That would be more conventional. It's an open question whether we're better off changing to the names that are the defaults (and documented) by git-flow, or we're better off choosing names that non-git-flow-ers will more easily recognize. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 06/04/2012 09:14 AM, Dave Abrahams wrote:
That would be more conventional. It's an open question whether we're better off changing to the names that are the defaults (and documented) by git-flow, or we're better off choosing names that non-git-flow-ers will more easily recognize. As a new user to a technology, it is sure nice when the defaults do the right thing out of the box without having to consult detailed documentation.
On 06/04/2012 06:14 PM, Dave Abrahams wrote:
on Sun Jun 03 2012, Beman Dawes<bdawes-AT-acm.org> wrote:
At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library.
Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names.
The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master).
Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches. That would be more conventional. It's an open question whether we're better off changing to the names that are the defaults (and documented) by git-flow, or we're better off choosing names that non-git-flow-ers will more easily recognize.
Branch names that non-git-flow-ers will more easily recognize are release and trunk. So trunk will in glt-flow change name to develop. Seriously, this is not worth thinking about as it will create a lot more confusion and grief with regard to git-flow documentation and tools. Keep the git-flow names. -- Bjørn And how may they be more
participants (8)
-
Beman Dawes -
Bjørn Roald -
Brian Schrom -
Daryle Walker -
Dave Abrahams -
Steve M. Robbins -
Vicente Botet -
Vicente J. Botet Escriba