When you're doing branching do you usually set up a trunk? What is the point? Why not just use the latest 1.0.x or whatever branch you have and do all your development there and tag it ( what is the trunk actually use for other than tradition? ). It seems I apply changes to the trunk and then merge into my latest branch ( there is no difference between that branch and my trunk? ). Or do try to keep the branches stable and thats why? Either way you wouldn't tag it unless it was stable but I guess it makes senese to have a trunk to commit to while you're stabilizing the branch? Did I answer my own question?
Where do you usually apply your bug-patches? The trunk? WHen you merge changes from the trunk to a various branch, and then change more on the branch, how do you properly re-integrate? You have to track the revisions you merged from the trunk into the branch, and merge all revisions but those to prevent "remerging in code twice" ?
Thanks
Subversion branching methodology
Moderator: General Moderators
Re: Subversion branching methodology
I guess volatile changes should go in the trunk and the release branches are where you do your bug fixes? Bump...
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Subversion branching methodology
From what I understand of the three "trunk", "tag" and "branches", the trunk is the place for the latest/newest version of your software (potentially lots of bugs) while the branches is for major releases of your software. This way you can fix bugs in version 4.4.7 of your software without applying the new features of 5.3 for the wrong version allowing you to develop several different versions of your software. This is what PHP does. They develop older branches forever. Anyway, when you are releasing a new version (e.g. RTM, RC, beta, alpha), then you use the tag for it. The use for that is the fact you can go back later and reproduce any bugs or re-release it later.
I'm not sure if that answered to your question at all.
I'm not sure if that answered to your question at all.
Re: Subversion branching methodology
Right, so you merge specific revision ranges from the trunk ( to get only the changes that were bug fixes )...and then merge that into the applicable branches as well? is this the proper way to do the bug fixes?kaisellgren wrote:From what I understand of the three "trunk", "tag" and "branches", the trunk is the place for the latest/newest version of your software (potentially lots of bugs) while the branches is for major releases of your software. This way you can fix bugs in version 4.4.7 of your software without applying the new features of 5.3 for the wrong version allowing you to develop several different versions of your software.
Or do you do the bug-fix on the branch and then merge that into the trunk. Which is going to yield less conflicts from your experience?
Bug fix on trunk or on branch?
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Subversion branching methodology
I would say it is advisable to commit bug fixes into the trunk and merge them into the applicable branches. Sometimes, though, I need to do it the other way around, because the latest development version isn't as important as some branches used by the current customers. Also, merging changes isn't always that cool if the code has changed a lot. Basically you would need to do the job manually at times. I once fixed a bug in a branch and merged it to other branches as well, but I had to fix the trunk separately as it was entirely different code. So, I don't think there's a definite answer to your question. Usually I go with the "bug fix on trunk".
Re: Subversion branching methodology
Ok Thanks, I have found myself in another state of confusion regarding branching, let me explain...
I have a separate add-on product to my core product. For this I have branched development and develop the additional functionality on that branch. When I add functionality or bug-fixes on the standard branch I merge that into my "addon" branch, so basically the "addon" branch is always the same as the "core" branch just with extra methods & lines of code here and there. It doesn't differ much at all actually ( in architecture or merge-ability ).
When I tag this what is the best way to manage the release #s? Right now my software is at like v0.9.2, I am "beta"-ing the addon functionality with a client and about to release it with an official version #. Is it best to try to coordinate the version #s between these two products?
For example whenever I change the core it changes the addons too, so all version #s would increment and get the change, so lets say if i did that I would have
core-0.9.3
addon-0.9.3
Then let's say I had a problem that just affected the addon package, would the best practice be to advance that version #s? That way users can clearly see that it changed, but is otherwise a part of the "0.9.3.x release(s)"
core-0.9.3
addon-0.9.3.0.1
Then the next time core code had to change it would look like:
core-0.9.4
addon-0.9.4
Do you think this is common and can you think of any projects that do something similar off the top of your head?
I am trying to think of the best way, including ambiguity when publishing release notes. For example should I branch my actual change log or have separate change log files? I imagine it would take discipline to make sure if I advanced the addons version #, that if I later advanced the core version # not to use a release # that the addon was released under, to avoid ambiguity
For instance I would not want in my release notes
Sept 22 v1.2.3 changed xyz
Sept 24 v1.2.3 changed abc
( it would not make sense that v1.2.3 was released on 2 dates, how do I coordinate that best? )
I have a separate add-on product to my core product. For this I have branched development and develop the additional functionality on that branch. When I add functionality or bug-fixes on the standard branch I merge that into my "addon" branch, so basically the "addon" branch is always the same as the "core" branch just with extra methods & lines of code here and there. It doesn't differ much at all actually ( in architecture or merge-ability ).
When I tag this what is the best way to manage the release #s? Right now my software is at like v0.9.2, I am "beta"-ing the addon functionality with a client and about to release it with an official version #. Is it best to try to coordinate the version #s between these two products?
For example whenever I change the core it changes the addons too, so all version #s would increment and get the change, so lets say if i did that I would have
core-0.9.3
addon-0.9.3
Then let's say I had a problem that just affected the addon package, would the best practice be to advance that version #s? That way users can clearly see that it changed, but is otherwise a part of the "0.9.3.x release(s)"
core-0.9.3
addon-0.9.3.0.1
Then the next time core code had to change it would look like:
core-0.9.4
addon-0.9.4
Do you think this is common and can you think of any projects that do something similar off the top of your head?
I am trying to think of the best way, including ambiguity when publishing release notes. For example should I branch my actual change log or have separate change log files? I imagine it would take discipline to make sure if I advanced the addons version #, that if I later advanced the core version # not to use a release # that the addon was released under, to avoid ambiguity
For instance I would not want in my release notes
Sept 22 v1.2.3 changed xyz
Sept 24 v1.2.3 changed abc
( it would not make sense that v1.2.3 was released on 2 dates, how do I coordinate that best? )
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Subversion branching methodology
Well there has to be some way for you to know which x versions of modules can be used with y versions of cores. This sounds similar to DLL Hell issue.josh wrote:When I tag this what is the best way to manage the release #s? Right now my software is at like v0.9.2, I am "beta"-ing the addon functionality with a client and about to release it with an official version #. Is it best to try to coordinate the version #s between these two products?
The version numbers represent the change between versions. The usual case is major.minor[.build[.revision]] in which the above kind of versioning would break the meaning of the versioning you are using.josh wrote:core-0.9.3
addon-0.9.3.0.1
Most projects that I know keep track on which versions of modules work with the latest version.josh wrote:Do you think this is common and can you think of any projects that do something similar off the top of your head?
Personally I would use separate change logs for each module. You just gotta find the way to connect different versions of modules to the right versions of cores.josh wrote:For example should I branch my actual change log or have separate change log files?
Re: Subversion branching methodology
Yeah I'm doing a branch, if they upgrade they get a different "edition" that installs ontop of ( read replaces ) the standard edition. Much better to avoid plugins for plugins.
Here is what I settled on
Lets say I made a change in standard edition, i release both:
0.9.1
0.9.1-ug
because the "ug" ( upgrade) package changes whenever the standard one does.
Let's say I made a bug fix in just the "ug" package, I'd release 0.9.2-ug the next point release for the standard package would now be 0.9.3 ( which would in turn merge into the upgrade branch and tag as 0.9.3-ug )
So basically
0.9.1
0.9.1-ug
0.9.2-ug
0.9.3
0.9.3-ug
( the standard versions would just skip point releases ). I think this will work what about you? That way if someone has v0.9.3-ug ( upgrade ) all changelogs & documentations correspond at all times with v0.9.3 ( standard )
Here is what I settled on
Lets say I made a change in standard edition, i release both:
0.9.1
0.9.1-ug
because the "ug" ( upgrade) package changes whenever the standard one does.
Let's say I made a bug fix in just the "ug" package, I'd release 0.9.2-ug the next point release for the standard package would now be 0.9.3 ( which would in turn merge into the upgrade branch and tag as 0.9.3-ug )
So basically
0.9.1
0.9.1-ug
0.9.2-ug
0.9.3
0.9.3-ug
( the standard versions would just skip point releases ). I think this will work what about you? That way if someone has v0.9.3-ug ( upgrade ) all changelogs & documentations correspond at all times with v0.9.3 ( standard )