Hi,
Thanks Andy and David for your answers.
As I said, it was just a supposition in a case where it becomes necessary to
fix all previous releases (for whatever reason). And in this case, I too
think not to touch the tag itself rather as per David's advise, branch the
tag 1.6, fix it and then release it as 1.6.1 tag.
However, in my case, its a typical web application providing online
payment services to web users. Where, the chances of deploying previous
releases are very less. Because the advancement goes on with the new
features adding in site and making it more productive.
*David says:
> *
*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.*
>
In this case, how I will update the bug fix in REL-1.7 which I fixed in
1.6.1 tag ? Is it the developer's responsibility to redo the bug fixing
steps on REL-1.7 which he did in REL1.6 ? Or is there any automated process
provided by SVN ? Because latest development is going on REL-1.7 which do
posses the bug of REL1.6.
Also, in case of web-applications what is the best practice to deploy
REL-1.7 on production ? Do we replace whole REL-1.6 code with REL-1.7 or
just update the production with modified binaries of REL1.7 ?
Bye,
Viki,
On Mon, Apr 19, 2010 at 10:46 PM, David Weintraub <qazwart_at_gmail.com> wrote:
> 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-21 10:27:47 CEST