Personally, I would still release them in staged/known releases than haphazzard fix on the fly.
You will find it's a much better process and easier to manage. "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com -----Original Message----- From: AJ Mercer To: CF-Talk Sent: Tue May 15 08:58:20 2007 Subject: Re: deploying changes from subversion I am not sure if I am making complicated than it needs to be, or if I am not explaining what I am trying to achieve It's not that I choose to only fix 3 bugs I am super quick and have got mods for all of them :-p It's just the fixes can hang around it test for any number of days. The testers get back to me and say they are happy with two of them, and are still testing the rest or maybe one of them needs more work. On 5/15/07, Robertson-Ravo, Neil (RX) <[EMAIL PROTECTED]> wrote: > > Hi AJ, > > You don't need to wait for signoff of all 5 bugs if you need. It comes to > how severe they are based on your bug tracking. Obviously your goal is to > ship as big free software as possible but there is obviously going to be > known issues and undocumented features. :-). It also depends on what > software development cycle you want to run with. > > With your SVN, imagine you have 1 project - Project1 which has the usual > branches, tags and trunk (I have never ever had to use branches - had no > need). > > Assume that test, dev and production are all the same code base as if they > are not, it maked version control a little trickier. > > So, your trunk / dev code is now version 1.0.0 (major, minor, maintenance) > but it's never labelled as such in SVN - you just know that is the build > you > are working *to*. > > You finish a set of features etc and want to release to test. Now, at > this > point you tag the trunk as 1.0.0. It is this tag which is released to > test > and your trunk now becomes 1.0.1 (or whatever release point you deem). > Again, this is not labelled as such it's what you are working to. > > If you get 5 bugs in build 1.0.0 in test then you fix them in 1.0.1. If > you > only want to fix 3 then release again then you follow the same above - tag > trunk as 1.0.1 and release to test. Your trunk then becomes 1.0.2 and so > on > and so forth. > > At any one point you will know what release is on what system and you know > your trunk will always be in line + current development. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 and Flex 2 Build sales & marketing dashboard RIAâs for your business. Upgrade now http://www.adobe.com/products/coldfusion/flex2?sdid=RVJT Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278136 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
