I think that all of what you describe is possible with (a current version like 1.7 or 1.8 of) Subversion. Here are the steps to take:
- Describe your branching (and merging) strategies. You cannot easily mix all of them, and it is difficult for developers to know which strategy is used where, so documentation and communication is here key. See the following resources:
- You will use the following:
- Release branch for the production release, patches are developed directly there. For each patch, you have to decide, if that patch should be available (in the same form) in the next release.
- Use the trunk for the main development. Everything you are sure that will be in the next release should be developed on the trunk. Don't merge from the trunk to (release) branch. Never ever!!
- Use feature branches only if you are unsure if a feature will make it to the next release. Feature branches are (in Subversion) much more difficult than e.g. in Git, so there should be a reason to use them. Merge all changes from the trunk to the feature branch regularly, and only reintegrate at the end, when the feature is integrated in the trunk (to make it to the next release).
- Find the right point in time for doing the branching and merging:
- Branching: When is a stable release branch necessary (for integration to the next release), and when can development start for the following release (then on the trunk again)?
- Merging: When is the best time to merge changes: Immediate, when the change is fresh; regularly from time to time; (hopefully not) only once at the end.
Your branches will be developed over time like this:
- You start with the trunk (and only the trunk) for release 1.0, your first release.
- You branch the trunk, when you want to do integration testing for release 1.0, and start development for release 1.1 (on the trunk).
- You deliver release 1.0, and provide afterwards patches directly from the branch.
- You branch the trunk, when you want to do integration testing for release 1.1, and start development for the release 1.2 (or 2.0) on the trunk.
- ... and so on ...
Branching and Merging of the SVN Red Book explains everything that you need technically, but is not so clear how to do it in different business contexts (my personal opinion). I don't have found a resource that explains all options and drivers behind them in enough detail ...