On Mon, Apr 19, 2010 at 3:14 PM, Vikrama Sanjeeva
<viki.sanjeeva_at_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
qazwart_at_gmail.com
Received on 2010-04-19 21:47:04 CEST