[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Best practice for release management

From: Dieter Oberkofler <d.1234567890_at_qualiant.at>
Date: 2007-05-09 18:42:14 CEST

Dear SVN Gurus,

Need your advice on how to best use SVN for a typical release management: We
currently create a tag for each version we need to support and embed the
version and revision number in the application to uniquely identify it. If
we unfortunately need to fix/change a past version
(/svn-rep/app/tags/tagged-version-6.7.0) and we cannot force someone to use
the latest version, we currently would:
1) Create a branch of the tagged revision we need to work on
(/svn-rep/app/branches/fixes-for-tagged-version-6.7.0)
2) Checkout this new branch to a local working copy
3) Make the needed changes to fix the problem (and increment the patch index
in our 3-number version number to 6.7.1)
4) Commit the changes to this new branch
5) Create a new tag as a copy of the new branch
(/svn-rep/app/tags/tagged-version-6.7.1)
6) Remove the branch (/svn-rep/app/branches/fixes-for-tagged-version-6.7.0)
7) Go to 1) (hopefully never again)

I was wondering if this is the best way to do so and what the best practices
regarding workflow, naming conventions, version numbering etc. would be?

Thank you
-Dieter

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 9 18:40:17 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.