On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote:
With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials.
Well the question isn't really about having many branches. The question is what happens when you have stable and development branches, and you want to "jump" the stable branch to mark retiring an old stable version and starting a new one? Doesn't that involve a nasty merge or rebase?
I can do some research, but I was hoping someone knew the answer....
-----Original Message----- From: asdf-devel [mailto:asdf-devel-bounces@common-lisp.net] On Behalf Of Robert Goldman Sent: 18 November, 2015 21:17 To: asdf-devel@common-lisp.net Subject: Re: Suggestions for procedure going forward
On 11/18/15 Nov 18 -8:35 PM, Faré wrote:
Yeah, there's an awkward merge or rebase happening when "stable" jumps from 3.1 to 3.2, whereas no such jump happens if old branches have numbered names and are forked off a master that keeps going forward.
Surely git must have a solution to this problem? There must be a ton of projects that need to have a "stable" and a "development" branch. So this must arise all over the place....
Anyone know?
On Thu, Nov 19, 2015 at 12:55 AM, Robert Goldman rpgoldman@sift.net wrote:
On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote:
With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials.
Well the question isn't really about having many branches. The question is what happens when you have stable and development branches, and you want to "jump" the stable branch to mark retiring an old stable version and starting a new one? Doesn't that involve a nasty merge or rebase?
I can do some research, but I was hoping someone knew the answer....
My bet is that they use versioned names for branch, and so never have to jump.
There is no branch called "stable", there is just the 3.1 branch, the 3.2 branch, etc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Exploitation is a word often used but rarely defined. In its most literal meaning — I 'exploit' you if I in some way benefit from your existence — it is the reason human society exists. We all benefit from one another's existence. We all exploit each other." — D. Friedman, The Machinery of Freedom
On Thu, Nov 19, 2015 at 12:55 AM, Robert Goldman rpgoldman@sift.net wrote:
On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote:
With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials.
Well the question isn't really about having many branches. The question is what happens when you have stable and development branches, and you want to "jump" the stable branch to mark retiring an old stable version and starting a new one? Doesn't that involve a nasty merge or rebase?
I can do some research, but I was hoping someone knew the answer....
My bet is that they use versioned names for branch, and so never have to jump.
There is no branch called "stable", there is just the 3.1 branch, the 3.2 branch, etc.
That's exactly what we do, just not so fine-grained at the minor number but cutting off the release name at the major number.
We use a 'release-3' branch which contains the tags 3.0.0, 3.1.0, 3.2.0, etc. and when the deveopment branch is ready for preparing 4.1.0, we branch off a 'release-4' which will be tagged 4.0.0 at some point in time.
Depending on how often we change the major version number, we either keep the release-x branches in the repo indefinitely (which is usually the case) or we merge them back into development ('master' in Faré's proposal) using
git checkout master git merge -m "Merging branch release-3 with -s ours" -s ours
After that, the content of master is exactly the same as before, but branch release-3 is merged into master without any conflicts.
Using this method, history is preserved, but the branch can be safely removed to avoid old branches littering the repo.
HTH
Kambiz
"Far" == Far <Far> writes:
Far> On Thu, Nov 19, 2015 at 12:55 AM, Robert Goldman rpgoldman@sift.net wrote: >> On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote: >>> With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials. >> >> Well the question isn't really about having many branches. The question >> is what happens when you have stable and development branches, and you >> want to "jump" the stable branch to mark retiring an old stable version >> and starting a new one? Doesn't that involve a nasty merge or rebase? >> >> I can do some research, but I was hoping someone knew the answer.... >> Far> My bet is that they use versioned names for branch, and so never have to jump.
Far> There is no branch called "stable", there is just the 3.1 branch, the Far> 3.2 branch, etc.
That's basically how I've always done it. Create a branch-3.1, branch-3.2 to develop the branches, and tag them at various points for 3.1.0, 3.1.1, etc.
Master is always the current development/unstable branch. Various topic branches for new ideas or new features are created.
And then merge/cherry-pick the necessary changes to keep branch-3.1 with the necessary changes.
And I never delete the release development branches; they should stay forever so you can go back in time. (I never delete any branch, but that's just me.)
-- Ray
OK, let me see if I can summarize before doing anything irrevocable to the git repo.
We will continue to have master, and will now also have a long-lived "stable-3.1" branch.
On master, we can start by bumping the ASDF version number to 3.2.0.1, and we will continue to versioning until we get to our first 3.2 release, which will be 3.2.1.
We will continue to tag our versions as before.
Is this an accurate reflection of the consensus approach?
-
Faré -
Kambiz Darabi -
Raymond Toy -
Robert Goldman