1

In the company i'm working on we have releases every x amount of time (usually three months). During that time, we have between four-six 'branch-releasable' sprints and all our code goes into that branch.

Some time later the branch is released as version xxx and we just move on to the next version. But due to usual commitments we have to keep in maintaining, for months/years, old versions.

I wonder if the branch as version-to-release is correct. Because of this our release-version-branch are never fully reintegrated into the trunk. They live forever. To maintain them, when a bug is found in the branch we fix it in the trunk and manually port it to the branch (i prefer this one) or instead we work in the branch and port it (sort of a commit branch in trunk without reintegrate) back to the trunk. Notice that for sure it could happen that the trunk contains code that won't/can't be merged into a branch maybe because that branch is just way too old to support a huge change.

Do you know benefits/cons of the methodology we use ? do you have another way to deal with maintainable versions ? maybe outside svn ?

Julian
  • 253
  • 3
  • 14

3 Answers3

2

There are basically two different "trunk policies": stable trunk where the trunk should always be releasable quality and all development takes place in reintegrated branches, and unstable trunk where the active development takes place in the trunk, and it is branched for stabilization before release.

Regardless of which trunk policy is used, a released version should always be a branch that is not reintegrated.

An example following the unstable trunk policy (active development in trunk, that needs to be branched for stabilization before it is released):

Development progresses in the trunk for 1.0. At some point a branch for 1.X is created and the code is stabilized. Once the code is deemed stable, it is tagged 1.0 and released. Meanwhile work progresses in the trunk for version 2, which will soon be branched in a 2.X branch and so on.

A bug discovered in version 1.0 can be fixed in the 1.X branch, and version 1.1 can released from that branch with the bugfix. If the bug is relevant in the trunk, it can be merged. But the feature may be removed or rebuilt in the trunk, making a merge of this bugfix to the trunk pointless or impossible. If the bug was discovered in the trunk by a beta tester of version 2, then you can fix it there, and later see if old maintenance branches such as 1.X has the bug, and then merge the bugfix there. It works both ways.

I don't see how there can be a better policy than branching for each version (in my example a branch per major version, not per release), and I don't see a situation where a version/release branch should be reintegrated into the trunk.

Anders Forsgren
  • 10,827
  • 4
  • 40
  • 77
1

I wonder if the branch as version-to-release is correct.

Well, at least it is not totally incorrect - you have manageable code all time. Not-fully-reintegrated branches are your internal game, which you can play while it doesn't destroy main task - release product as the time comes and fix older problems. Diverged lines of code is your cost

From PM POV your "mixed" workflow (2 sources, mergesets and ordinary linear history in branch) in harder for conversion from log into final "Done-List" for release, I'll prefer, advertise and campaign for "branch-per-task" workflow (in any SCM) - this way branches (development, most) are short-live, integrable part of work and mainline&versions branches will get only mergesets, which are easier to observe. But it's only personal preferences and tastes

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • So do i (branch per task/feature). But i used to work in a non releasable environment (web app). Now i work in a browser app which has releases to multiple customers and that's why i wanted to know if that concept is ok. I agree it's ok. It's just .... a bit messy but i assume maintaining old versions is always messy. – Julian Oct 16 '12 at 17:46
0

I think I will always keep the latest stable code in the trunk and current development version will be there in branch (there will be many versions in the branch since different people will be working on different requirements).After that when my code will be ready to release I will merge it to the trunk since that will be a latest stable code. At the same time I will tag it with the latest version number and release date into the tag folder.

Now since you have latest stable code into the trunk and latest released source code into tag you can delete that particular branch.

ganesh
  • 1,006
  • 14
  • 30
  • That is correct but that doesn't solve he problem of dealing with maintaining old versions. If we delete the branch we'd have to make changes to the tag (which by the way is the same concept for svn). – Julian Oct 16 '12 at 17:23