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 ?
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