You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Vikrama Sanjeeva <vi...@gmail.com> on 2010/04/19 19:14:27 UTC
fixing bug in multiple releases
Hi,
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"
?
Bye,
Viki.
Re: fixing bug in multiple releases
Posted by Vikrama Sanjeeva <vi...@gmail.com>.
On Wed, Apr 21, 2010 at 8:13 PM, Les Mikesell <le...@gmail.com> wrote:
> On 4/21/2010 8:48 AM, Vikrama Sanjeeva wrote:
>
>>
>>
>
>> 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 ?
>>
>>
>> Normally you would want to work in a way that gives you a known
>> 'roll-back' state in case the next change introduces problems. If
>> you don't keep a whole release together you'll have to track the
>> individual changes to know how to reproduce the last working state.
>>
>>
>> So you actually mean that for every change (big in size like 5-10+
>> files) whole code should be replaced with new release, while keeping an
>> option of "roll-back" ?
>>
>
> There are different tradeoffs depending on how the application works and
> where you need to deploy, but a good arrangement is to have a 'staging'
> server where you can update or switch to a release tag and execute/test
> directly from the workspace, then use a scripted 'rsync -C ...' type of
> command to propagate to the production server(s). Rsync is smart enough to
> (a) only copy the changes and (b) receive under a different name, renaming
> only when the transfer is complete and successful. If you never make
> changes in the staging workspace you guarantee that what you test and push
> to production is a reproducible copy from the subversion repository that you
> can recall if you need to revert to that version later.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
Agreed. We do use staging for testing and UAT with client and if all works
good then only planned deployment is done on production. However, I like
your idea of "rsync -C.." command for deploying "accurate" changes from
staging to production. But I think in this case, deployment engineer should
be confident that only change related to a specific feature is present on
staging and ready to ship on production. Because, if there are multiple
features residing in staging but only certain features qualifies for
production then running "rsync -C..." will be expensive.
Bye,
Viki,
Re: fixing bug in multiple releases
Posted by Les Mikesell <le...@gmail.com>.
On 4/21/2010 8:48 AM, Vikrama Sanjeeva wrote:
>
>
> 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 ?
>
>
> Normally you would want to work in a way that gives you a known
> 'roll-back' state in case the next change introduces problems. If
> you don't keep a whole release together you'll have to track the
> individual changes to know how to reproduce the last working state.
>
>
> So you actually mean that for every change (big in size like 5-10+
> files) whole code should be replaced with new release, while keeping an
> option of "roll-back" ?
There are different tradeoffs depending on how the application works and
where you need to deploy, but a good arrangement is to have a 'staging'
server where you can update or switch to a release tag and execute/test
directly from the workspace, then use a scripted 'rsync -C ...' type of
command to propagate to the production server(s). Rsync is smart enough
to (a) only copy the changes and (b) receive under a different name,
renaming only when the transfer is complete and successful. If you
never make changes in the staging workspace you guarantee that what you
test and push to production is a reproducible copy from the subversion
repository that you can recall if you need to revert to that version later.
--
Les Mikesell
lesmikesell@gmail.com
Re: fixing bug in multiple releases
Posted by Vikrama Sanjeeva <vi...@gmail.com>.
On Wed, Apr 21, 2010 at 3:42 PM, Les Mikesell <le...@gmail.com> wrote:
> Vikrama Sanjeeva wrote:
>
>>
>> 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 ?
>>
>
> Normally you would want to work in a way that gives you a known 'roll-back'
> state in case the next change introduces problems. If you don't keep a
> whole release together you'll have to track the individual changes to know
> how to reproduce the last working state.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
>
So you actually mean that for every change (big in size like 5-10+ files)
whole code should be replaced with new release, while keeping an option of
"roll-back" ?
Bye,
Viki.
Re: fixing bug in multiple releases
Posted by Les Mikesell <le...@gmail.com>.
Vikrama Sanjeeva wrote:
>
> 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 ?
Normally you would want to work in a way that gives you a known 'roll-back'
state in case the next change introduces problems. If you don't keep a whole
release together you'll have to track the individual changes to know how to
reproduce the last working state.
--
Les Mikesell
lesmikesell@gmail.com
Re: fixing bug in multiple releases
Posted by Vikrama Sanjeeva <vi...@gmail.com>.
On Wed, Apr 21, 2010 at 5:18 PM, David Weintraub <qa...@gmail.com> wrote:
> On Wed, Apr 21, 2010 at 4:27 AM, Vikrama Sanjeeva
> <vi...@gmail.com> wrote:
> > 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.
>
> This is a web-based service? In that case, there's probably little
> reason to fix the previous releases at all. Why fix release REL-1.4 if
> it isn't even deployed any more?
>
> I can see a situation where you have REL-1.6 deploy and are about to
> deploy REL-1.7. You deploy REL-1.7 and then are forced to rollback to
> REL-1.6.
>
> In that case, you probably want to fix the bug and roll our REL-1.6.1
> while you're trying to fix the problem with REL-1.7.
>
Agreed.
>
> > 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 ?
>
> Do you have an automated deployment abilities? My preference is to
> have an automated way of deploying apps. You want to make sure that
> the binaries, database changes, and any preference file changes are
> all deployed and properly configured. Just replacing the binaries
> might not do it.
>
We don't have automated deployment process. Normally, its compiled code
which has to go in certain hierarchy on production whenever we have change.
We normally do this by transferring binaries via FTP which is fast and
working effeciently since last year without any error. However, in case of
database, we have scripts to database department which cross-checks the
scripts and run accordingly. In case of roll-back we normally do not touch
database. There might be a need to do this, but we never had a situation.
However, my one question is still left un-answered. I will appreciate if you
can guide in this regards.
*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.
Bye,
Viki.
Re: fixing bug in multiple releases
Posted by David Weintraub <qa...@gmail.com>.
On Wed, Apr 21, 2010 at 4:27 AM, Vikrama Sanjeeva
<vi...@gmail.com> wrote:
> 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.
This is a web-based service? In that case, there's probably little
reason to fix the previous releases at all. Why fix release REL-1.4 if
it isn't even deployed any more?
I can see a situation where you have REL-1.6 deploy and are about to
deploy REL-1.7. You deploy REL-1.7 and then are forced to rollback to
REL-1.6.
In that case, you probably want to fix the bug and roll our REL-1.6.1
while you're trying to fix the problem with REL-1.7.
> 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 ?
Do you have an automated deployment abilities? My preference is to
have an automated way of deploying apps. You want to make sure that
the binaries, database changes, and any preference file changes are
all deployed and properly configured. Just replacing the binaries
might not do it.
--
David Weintraub
qazwart@gmail.com
Re: fixing bug in multiple releases
Posted by Vikrama Sanjeeva <vi...@gmail.com>.
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 <qa...@gmail.com> wrote:
> On Mon, Apr 19, 2010 at 3:14 PM, Vikrama Sanjeeva <viki.sanjeeva@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@gmail.com
>
Re: fixing bug in multiple releases
Posted by David Weintraub <qa...@gmail.com>.
On Mon, Apr 19, 2010 at 3:14 PM, Vikrama Sanjeeva
<vi...@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@gmail.com
Re: fixing bug in multiple releases
Posted by Andy Levy <an...@gmail.com>.
On Mon, Apr 19, 2010 at 15:14, Vikrama Sanjeeva <vi...@gmail.com> wrote:
> Hi,
>
> 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"
> ?
Most release strategies don't "slipstream" bug fixes into previous
versions. That is, one wouldn't normally backport a fix to the
previous 6 releases, just release a new release N+1 which fixes it and
inform people using the older versions to upgrade.
Otherwise, version 1.2 from last week is not the same as version 1.2
this week. A lot of confusion would result.