Handling software versions, branch or label/tag?

[Vaulty]

Greetings,

Say we have software where different customers are using different versions.

So there is version 1.0, 1.5, 1.9 and internally we are also developing version 2.0.

Now how would we use Vault to manage the various versions and current development build (2.0)?

Again we are still supporting versions 1.* so we will need to go back and fix bugs and propogate the fixes accross the other versions potentially.

Do we store versions 1.* as a branch or a tag/label? (please describe the process if possible).

[Beth]

The easiest is to have your trunk be your continuing development and then each branch is a release. I'm assuming that when you make a fix to an old version, you also need that fix in the newer versions, right? That's where a branch is helpful, because you can merge that change back into the trunk.

Here is a link to our best practices articles that may help:

• Best Practices for Managing Branches
  Basics of using Label, Cloak, Share, Pin, Branch and Merging

[salibhai]

Lets say we have 5 different new features for our application, each worked on by 1 or 2 developer. Are you saying they all (10 developers) develop in the trunk, and then we move the code into a branch only when its ready to be released?

Thanks
Sameer

[Beth]

The idea of making a branch when you release is so that development can continue in the trunk, but yet fixes can be applied to the release separately (that's the branch), and then the fixes are merged back to the trunk if needed there as well. In that respect, you develop in a trunk, you're ready to release you will branch the code and release the branch. You will probably also want labels applied either in the trunk or the branch or both so that you can compare the release versions to changes made.

[salibhai]

How about if you are developing multiple features all in the trunk. When you branch, aren't you going to end up with multiple unfinished features in the new release branch?

[Beth]

If you started materials for the next one, then yes. You want to branch before you start putting in code that won't go into that release.

Some of this is preferences on how to work as well, so you will have to look at how your team likes to do things and make a few decisions.

Let's say you have code happening for versions 2, 3, and 4 all at the same time. Version 4 is the farthest out, and all their own separate major release. This is where it's down to your team to make the decision. If the code for version 4 is dependent on versions 2 and 3, then you have quandary there, because if you code versions 2 and 3 in a branch, then 4 can't go anywhere until that code is merged in. If not, it would make sense to me to have either 2 branches for versions 2 and 3 (or 1 branch if they can be coded together for a while), and to have version 4 continue forward in the trunk to be branched out later.

Basically, at the point you don't want something to be grouped with the development that moves forward in the future (the future being the trunk), then you branch it out. When that decision is made is more of your team's decision. Some only do it upon release, some when a new feature is coming in, and some come up with more creative ways such as not putting the buttons in for a feature until it's part of a release and branched out so the feature can't be used.

Your best bet is to look at the 2 articles I posted. The more "official" word from those articles is "the trunk is where current development occurs, and
the branch is for the finished version and any maintenance releases." But, this can be adjusted around how you want to work as well. If you get too many branches going, you may run into some confusion and it creates more nodes in the tree which can potentially slow performance if it gets to be a huge number.

Try to avoid getting yourself into a situation where you merge a trunk into a branch. You will get best results if you keep the branches merging one way into the trunk.

[salibhai]

I did, thank you. Just trying to understand the specifics. I still have some questions in my mind, I am just trying to sort them out before I post them.