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

Re: Best practice for release management

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-05-10 00:13:12 CEST

"Dieter Oberkofler" <d.1234567890@qualiant.at> writes:
> 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?

Your workflow sounds sensible to me. Regarding release numbering,
etc, I've written a bit about that here, hope it helps:

   http://producingoss.com/html-chunk/development-cycle.html

-Karl

-- 
Subversion support & consulting  <>  http://producingoss.com/consulting.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 10 00:13:42 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.