How to deliver multiple application versions without confusion?

Question

We currently work on multiple branches of our web application. The VCS of choice is SVN.

We have:

• v1: /trunk, live application, bugfixing

• v2: /branches/1, additional features, without trunk bugfixes

There are more steps planned. The current plan is to have a stable and client accepted v1 and then merge v2 into v1. At that point it's for sure that v3 will pop up.

The problem is that the client needs more transparency, he can currently only see and test v1. If i'd make v2 available to them too, it's very likely that they can't tell the versions apart and report v1 (fixed) bugs again for v2. It would be a mess, imo. I also don't like the idea of a daily merge because it would be even harder to tell new and old bugs apart.

I have the feeling that this is more a problem with our development process than an technical one. Any inspirations to solve the problem or to make both sides feel more convenient about future development are welcome. Thanks.

edit

One partial problem is also that my co-workers aren't too deep into version-control, using 2 branches is already inconvenient for them. However if i find a better strategy i'll probably force them to do it right.

edit2

Thanks all for the answers. After some thinking it turns out that the whole problem is even bigger, because we keep binary files within SVN. Without very strict policies merging will be impossible and probably will be crippled anyway.

Answer 1

It seems kind of unorganized. Merging version 2 into version 1? Eh? What version are you left with? Still version 1? With the features of version 2? Wha..?

What I like for smallish projects:

Trunk: This is where things get committed when the developer is confident that it's working. Do internal QA testing on the trunk.

Tags: Make a new tag for each release, by copying from the trunk. Name your tags "/tags/v1.0" or "/tags/v1.1" or however you want to do it. If you need an external client to test something, name your tag something like "/tags/v1.0-beta" and give them that to test. Don't let them test with the trunk, because while they're testing you're still going to be developing!

Branches: When you've got a feature that's going to take some time to develop, you can't commit it to the trunk before it's done. Make a branch. Name it after the feature you're implementing, like "/branches/user_logins".

Bugfixes get committed to the trunk and are included in the next tagged release. If there's an emergency bugfix which must be released TODAY, but there's stuff in the trunk which can not yet be released yet, make another tag but copy from the tag of the buggy release instead of from the trunk, call it something like "v1.0.1", fix the bug there, give them a new release, and then merge that bugfix into the trunk.

Answer 2

1. "without trunk bugfixes"
2. "it would be even harder to tell new and old bugs apart."
3. "I have the feeling that this is more a problem with our development process than an technical one."

Damn straight. Your development process fails to acknowledge failures in V1. How can you hope that V2 will be better than V1 if you don't carry over the corrections in V1 to V2?!

Bug fixes are always more important than new features. If the old features are broken and not worth fixing then remove them.

Get off your lazy ass; if you, or someone, has made the effort to fix a defect in V1, then make sure it doesn't reappear in V2. FIX IT! If your code is so rubbish that this is a daily occurrence then stop working on V2 and focus on getting the bug fixes down to less often. If you can't get V1 features working properly then you'll never make it to V3.

I might also suggest "mercurial" or "git" or "bazaar" rather than svn. They're much better at keeping management types at bay if you find and use the "cherrypicking" and "queue" functionalities: you can add a feature and pull the-ONE-that-management-think-will-save-them into production without pulling all the other half-baked ideas they came up with then abandoned. If politics prevent a move to distributed version control just use it yourself and only push the stuff you deliver (and they want) to svn.

Answer 3

For me it seems that you switched the terms branch and trunk. Normally trunk is the active development branch, where releases live on their own bugfix branches. It looks that you use trunk as release1 bugfix branch, while /branches/1 is the real development trunk, and are stuck since you can't create a second trunk for release2.

If I'm right I would recommend to move your current trunk into a /branches/v2 branch, and your /branches/1 branch to /trunk. With this scenario you can have as many release branches as you need (but try to keep them as low as possible), while the main development line is in /trunk.

See http://nvie.com/posts/a-successful-git-branching-model/ for more details. While it is for git, there is a lot of VCS-independent information.

Answer 4

I agree to you other fellow posters. c0rnh0li0 You need to rethink your checkin & merge policies.

Look at your repository layout and try to define rules that can easily be repeated by anyone in the team and that help to populate changes consequently from stable to unstable. For me this allows merges mostly in one direction.

Example layout for a maintainance-branch scenario

branches/v1
-approved and shipped/deploy
-Only bugfixes allowed

branches/v2
-is not approved by the client but nearly ready
-Fixes and feature-commits allowed that focus on getting v2 stable & ready
-receive bugfixes commited in v1 (merge down)

branches/v3
-is not approved by the client and far from ready
-Fixes and feature-commits allowed that focus on getting v3 stable & ready
-receive bugfixes commited in v2 (merge down)

trunk
-All syntax-error free commits allowed (mainline)
-receive merges from LATEST stable branch (merge down from v3 in this case)

The top branch is the oldest with the fewest features but the highes stability (well tested, not many featurs been added in the recent past). The trunk on the other hand is pretty unstable and receives bleeding-edge features. v2 and v3 are Somewhet in between. You could also add featrue branches "below" the trunk which would be even more unstable than the trunk. Merge directions remain the same. I'd like to quote the mantra "merge down, copy up".

The more concurrent releases you prepare/maintain the more merges you will have to do though. But thanks to mergetracking it is not so much of a task IMHO and it ensures no bugfix is left behind and has to be re-discovered and fixed again manually.

I didnt mention tags here. If you can create them and do not release from a branch directly.

Now while this should fix your change-flow management to a great deal and help isolate high-risk development from low-risk, there is the issue left of visualizing to the client what he is testing/previewing.

---

Visualising application VCS origin to the client

Possibilities:

• If it is a web-projekt host, the versions on URLs that contain the branch-name
• For any project: Just check in a logo or text property that contains something like "version 3.x" and display it in your application
• Coolest solution is to use svn keywords and parse the value of $HeadURL$ in your app to dynamically display the branch name this build originates from