...that's what CruiseControl is for. Updating versions by hand is not reliable enough and there's nothing worse than not knowing which version of code is in which build. This goes for testing just as much as for customers logging issues.
If you have appropriate separation between your developers and Testers then every bug should be logged against a version/build number in which it appears and every fix should be logged against a version/build number in which it will emerge. The testers should only be using builds that come from an official manufacturing process outside development whose responsibility it is to update the version/build numbers. These folks run the ANT scripts in a clean environment. I would use a unique and incrementing build number rather than the latest svn rev unless your build process locks the repository, labels it and uses the rev of the label for the build number. A build number also makes your job a little easier because you can look back and know that there were no intermediate builds between 2.1.12 and 2.1.13 rather than 2.1.4653 and 2.1.4825. I strongly recommend going one step further and logging every source control rev number against every bug fix and every bug number against every rev, that way you can effectively cross-reference your source code, your builds/releases and your bugs. This probably all sounds like overkill but it is not really, it is just a bit of discipline in development which makes release management and subsequent bug tracking much easier. Once your developers get in the habit of doing it they'll not be able to live without it. And when it saves your life in a situation with a customer you'll legislate it in every subsequent project you work on. If you have any aspirations for your products to be sold into, used by, or partnered with large organisations you'll have to have these processes to effectively track your product iterations. If you ever sell into Government (esp. defense/security) you'll need them documented for audit purposes. --- In flexcoders@yahoogroups.com, Tom Chiverton <[EMAIL PROTECTED]> wrote: > > On Tuesday 19 Feb 2008, essuark wrote: > > The purpose of a version? Well to find out what version of the product > > the customer has for one... > > Right, so embedding the SVN revision number for the top level directory (or > better, the SVN tag/branch name) would do ? > This has problems, even using svn:keywords means you have to update that file > for every build. > So why not just have a constant stored in the Model and update it by hand ? > > 'Course, if you have an automated build process (i.e. ant) you can embed the > build date directly - Flex 3 has compiler constants (like -D in gcc). > > -- > Tom Chiverton > Helping to greatly maintain holistic eyeballs > on: http://thefalken.livejournal.com > > **************************************************** > > This email is sent for and on behalf of Halliwells LLP. > > Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. > > CONFIDENTIALITY > > This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. > > For more information about Halliwells LLP visit www.halliwells.com. >
