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.
> 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_at_gmail.com
Received on 2010-04-21 16:19:23 CEST