On Wed, Apr 21, 2010 at 5:18 PM, David Weintraub <qazwart_at_gmail.com> wrote:
> On Wed, Apr 21, 2010 at 4:27 AM, Vikrama Sanjeeva
> <viki.sanjeeva_at_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.
Received on 2010-04-21 17:53:45 CEST