Subversion source code policy

> The policy is: new code *always* goes to trunk. Release branches
> (like 1.1.x or 1.2.x) are in 'maintenance' mode, which means they
> receive backports of important bugfixes. (Release branches never
> receive new features.) When enough bugfixes have been backported, we
> do a new 1.2.x release from the branch.

I've seen you mention this policy once or twice before, and I was wondering if there was a detailed explanation anywhere of exactly
how you folks work? As a beginning user of Subversion, and being involved in the implementation of it here at work, I'm interested
in how others do things so that I can evaluate our practices here. If it's in the book and I missed it, I apologize and please
point me to it.

Do you just cut a release branch when enough features have been accumulated, or the features you want in the release are done? Do
you fix bugs on the trunk or in a branch then merge to trunk? Do you pick and choose the features that go into a release branch or
just include whatever is on the trunk at the time? Do you cut branches for major initiatives then merge back to trunk when they are
complete?

Yes, these are naive questions. I'm relative naive when it comes to deep discussions of version control.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 1 15:14:56 2005