"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