On Mon, Apr 19, 2010 at 3:14 PM, Vikrama Sanjeeva <viki.sanje...@gmail.com>wrote:
> Suppose I have total 6 releases in /tag which are considered as stable > releases. Now if, at 6th release we realize that there is a "bug" which > should be fixed in all previous releases then what should be the strategy ? > Is there any way in SVN which allows to fix bug in all releases "at-a-time" > ? > Our strategy is to never change a tag and that goes double for "release" tags. Releases should be hierarchical in nature. That is, REL-1.1 contains all the stuff in REL-1.0 and additional bug fixes and features. If you have someone in REL-1.0, and they want a bug fixed that is fixed in REL-1.1, they should be upgraded to REL-1.1 and not have REL-1.0 patched. Of course, there are exceptions to this rule, but you have to balance the number of versions of software you're maintaining with the number of releases you can track and maintain. Having each customer with a unique release would be bad management of your time and resources. So, the question is what are these six releases. If they're REL-1.0 through REL-1.6, you probably don't need to fix REL-1.0 through REL-1.5. Instead, you should create a REL-1.7 with the fix and upgrade everyone to that. Again, there are reasons why this might not be possible, but the ideal is to be able to keep yourself on as few releases as possible that you have to maintain. That said, let's say you're working on REL-1.7, but it isn't ready, and a bad bug was found in REL-1.6. You should copy the tag REL-1.6 to a branch, fix the bug on the branch, and then create a new REL-1.6.1 tag. That way, you can see that you had a REL-1.6 and what changes you had to make to get to REL-1.6.1. If you change the tag, you lose this information. Plus, you end up with two REL-1.6s: One with the patch and one without. How are you going to know the difference between the two REL-1.6. The way I do releases is always doing a release off a branch. Branches diverge in my scheme, that is the trunk and the branch diverge over time. For example, we get to a point where all the features in REL-1.6 are pretty much complete. We'll now be spending time patching bugs and optimizing the code. At this point, I create a 1.6 branch: $ svn cp http://path/to/project/trunk http://path/to/project/branches/1.6 This allows most of my developers to continue working on the next release while the few developers involved in getting REL-1.6 out the door will work off the branch. When we're ready to release, we tag the branch: $ svn cp http://path/to/project/branches/1.6 http://path/to/project/tags/REL-1.6 If we find a bug in REL-1.6, we can continue doing our work off the 1.6 branch, and fix the bug on that branch. Once we've finished, we can tag that work: $ svn cp http://path/to/project/branches/1.6 http://path/to/project/tags/REL-1.6.1 When we're about to do REL-1.7, I'll again branch from trunk to a 1.7 branch and we go on from there. So, to answer your question: * Should you update all of your tags? No, you shouldn't ever move a tag. Instead, create a branch you can work off of from the tag (if necessary), fix your bugs on the branch, and create a new tag. * Should you update all six releases? Probably not, but I can't say exactly what you should do without more information. Basically, if a customer is on an older release, and can upgrade to a newer release, you should have that client upgrade. If the client can't upgrade, you may have to make a branch based off of their current release, fix the bug on the branch, and then create a NEW release. Ideally, you should simply have to fix the last release, create a new tag, and upgrade all of your customers to that release, so you only have one release to support instead of six. -- David Weintraub qazw...@gmail.com