I am part of a team that releases versions of our software 4-5 times each year to our customers. We maintain the previous 2-3 versions of our product by correcting any errors that we come across in later versions. We are using TFS 2008 for source control and are trying to find the best way of maintaining the older versions.
We currently create a branch of our application each time we do a new version, but we are looking for a good way to update old versions more easily. For example, we complete 9.5 but two weeks after we created the branch and are working on 10.0, we realize that 9.5 has an error. We currently make the change in version 10.0 and then open 9.5 to make the change again. Is there anyway of automating this?
Thanks!
This is a main reason for branching and merging.
What I do in your situation is to make the change in 9.5 and then merge the change up into your main branch, and then back down into your 10.0 branch. The built in merge tool works well for this.
If you go the other direction you run the risk of adding new 10.0 stuff into your 9.5 branch when all you want is your bug fix.
I would also take a look at the TFS Branching Guides for more information on branching and merging.
If you are creating a branch of your main source, then you should be able to make the correction to the bug in your main source and then "merge" that change to your 9.5 and 10.0 branches. That's part of the beauty of branching, namely, you can merge your changes from your main branch to the target branches.
When you choose the merge option with TFS, it will show you where the current source is branched, and you can choose which branches you want to merge those changes to. You shouldn't have to make the changes in your 9.5 and 10.0 branches manually, that really sort of defeats the purpose of branching in the first place.
No, there is no way to "automate" this, and you dont really want to. What if the fix doesnt really need to be applied to each version?
It does sound to me like you are applying fixes backwards (first fix in older versions, then merge to newer).
Related
I've recently started working on my own project, I've added to project to github and I'm learning the reigns with using a source repository.
I have some questions as much of this is new to me:
Version numbers. How do I decide what qualifies as a new version? I work on the project daily
and make many small changes. do I write down a changelog? Should I add this with every version? What's Common agreed Practice?
What are the requirements and criteria for an Alpha buuild?
What are the requirements and criteria for a Beta build?
Since you are using git, use the commit history as your change log. Just make sure you are writing short but descriptive messages.
Most of the software I write is uses Major.Minor.Revision for my visioning.
Major - Software version. This will only increment if I make a huge
change to the code base or rewrite it all.
Minor - Release. This
changes when I merge changes from the development branch to the
master.
Revision - Patch number. this will constantly be changing,
this is how many times I have pushed to the branch since incrementing
the Minor.
An example would be:
1.0.0-dev -> 1.0.1-dev -> 1.0.2-dev -> 1.1.0-rc & 1.1.0-dev
Should I have to make a hot fix I would release 1.1.1-rc and 1.1.1-dev.
As for the requirements for alpha/aeta, you can set your own criteria but normally alpha is usually where you add features to your code and fix the major issues, and beta is where you fine tune your code.
Some good references that go into more detail than I have are:
http://en.wikipedia.org/wiki/Software_release_life_cycle
http://en.wikipedia.org/wiki/Software_versioning
If I have to change the source code of an app(Email, Browser, etc) for some custom requirement, I wonder how I should maintain the changes so that I can upgrade to the newer version of the app later when it's available.
I can thinking of maintaining the diff patch and applying to the newer version later but I am wondering if there are any best practices. Is it good to just fork off a branch and keep merging the newer changes into it?
Thanks.
Sony several times described their process. Here is the links:
http://developer.sonymobile.com/2013/07/25/explaining-the-software-upgrade-process-and-its-improvements-for-android-4-3/
http://developer.sonymobile.com/2011/12/07/ice-cream-sandwich-from-source-code-release-to-software-upgrade/
You should follow the disciplines that:
Keep your modifications aside from the original code as much as possible - this will save your effort if you have to do merge code later
Record your modification work in an appropriate way, you need to know why you made these changes and how you did it.
Don't expert to do a simple merge since the changes might not be fast-forward. Rebase your repository first and pick your changes and apply carefully.
I recently started taking an interest in using a branching model similar to Vincent Driessens Git branching model. We have multiple developers working on the same project so using different branches for different features is a big plus for us. The model states that after a feature is developed, it is merged back into the Development branch, and on a certain time a release branch will be created from it.
Now my problem is that I don't know who added what to the dev branch since the last release, but I do want to present a list of changes that will be implemented for the next one. So the question is, how do I know what features have been added to the dev branch?
We're using TFS for version control. As far as I know I have the following options:
Better labeling and commenting of versions (currently there is no labeling and little commenting)
Linking TFS tasks to versions (not sure how to create a nice list of that yet though)
Maybe I should just follow my own options above but I was curious about how you guys deal with this.
First I would suggest you take a look at the TFS Branching and Merging Guide as it will likely answer most of your questions.
how do I know what features have been added to the dev branch?
I think the "develop" branch in Driessen's model is most closely equated to the "main" branch in the TFS guidance. I would suggest that you shouldn't merge changes into main unless they are already planned to go into the next release. Then when you are ready to release you simply branch from the latest version of main.
Keeping track of what features are intended for the next release is something that would be handled by the work item tracking system.
Separately, you may find the Track Work Item feature of Team Explorer to be helpful.
If you have a version 1.0 of a product, or say 1.1 or even a patch, do you create a tag/label or a branch?
Eric Sink wrote a great series of articles about the ins and outs of version control. I'd suggest using those as a starting point.
Depends on the version control system. I'd branch for incompatible (major version number) changes, and tag for compatible (minor version number) changes. That leads to a whole discussion about what's compatible and what isn't, though...
Or, just use Subversion, where you'd normally use "svn copy" for either.
I usually don't branch but only label the releases. This way, I can branch later when the need arises. Since branches are so expensive in CVS, try to avoid them until you really need them. For all other VCS tools, branching is so cheap that you can do it as you need it, so no need for premature actions, either.
It depends a bit on the tool (version control system) you use, if it has sane branching and tagging.
In Git I would use tags such as v1.0, v1.1 to point to exact version (tags do not change), so if somebody would tell you that there is a bug in version 1.0, you would know exactly what it contains. If there would be a need for long-term maintenance, I would use branches such as maint-1.0 and maint-1.1 to gather maintenance bugfixes for past version, and from time to time tag new minor release such as v1.0.1, or v1.1.5.
HTH
Using TFS, when would you label your code and when would you branch?
Is there a concept of mainline/trunk in TFS?
A label in TFS is a way of tagging a collection of files. The label contains a bunch of files and the version of the file. It is a very low cost way of marking which versions of files make up a build etc.
A branch can be thought of as a copy of the files (of a certain version) in a different directory in TFS (with TFS knowing that this is a branch and will remember what files and versions it was a branch of).
As Eric Sink says, a branch is like a puppy. It takes some care and feeding.
Personally, I label often but branch rarely. I create a label for every build, but only branch when I know that I need to work on a historical version or that I need to work in isolation from the main line of code. You can create a branch from any point in time (and also a label) so that works well and means that we don't have branches lying around that are not being used.
Hope that helps,
Martin.
In any VCS, one usually tags when you want a snapshot of the code, to be kept as reference for the future. You branch when you want to develop a new feature, without disturbing the current code.
Andrew claims that labeling is lazier than branching; it's actually more efficient in most cases, not lazy. Labeling can allow users to grab a project at any point in time, keep a history of files changed for a version or build, and branch off of/work with the code at any point and later merge back into the main branch. Instead of what Andrew said, you're advised to only branch when more than one set of binaries is desired- when QC and Dev development are going on simultaneously or when you need to apply a hotfix to an old version, for example.
I always see labels as the lazy man's branch. If you are going to do something so significant that it requires a full-source label then it is probably best to denote this with a branch so that all tasks associated with that effort are in an organized place with only the effected code.
Branching is very powerful however and something worth learning about. TFS is not the best source control but it is not the worst either. TFS does support the concept of a trunk from which all branches sprout as well.
I would recommend this as a good place to read up on best practices - at least as far as TFS is concerned.