I create branches for each new features. Then I'm merges them into the trunk after I'll sending them on a test site.This means that the trunk is not stable.
I wonder if there is a better approach.
EDIT After reading the comment, I realize that I should have specified that it was a web applcation.So a website for testing each branch seems a bit difficult to maintain.
Why do you merge a development to the trunk before testing is finished? You could wait until testing made sure that the changes don't break your system before you merge them to the trunk,
What is your general merging strategy? Do you have release branches or do you release from the trunk?
Can you not get the branch tested before mergine back to the trunk?
Otherwise a Distributed Version Control System like Mercurial might be the way forward. With that you can define new repositories for each feature, and for testing, and push to the 'trunk' repository.
I prefer to keep the trunk always stable, I have a good discussion on the topic here
One thing is, you could test on the branch, before merging back. Also often the trunk isn't seen as the stable development, you make snapshots from time to time, fix bugs on them without adding features (or even remove features if they are buggy or incomplete) and release these branches as stable.
EDIT: To explain it a little further: Keeping feature branches for a long time separated from the main trunk can cause headaches for integration. Your team recognizes late conflicting changes - not only on source-level, but also on semantic or data-level. Keeping the trunk current uncovers such problems fast. Therefore I prefer to stabilize on a separate branch.
You can have branches/newfeatures and branches/stable
The trunk isnt stable, but when you "freeze" the trunk in a branch... then that is the stable branch.
I use the following:
branches: don't always compile, not always stable
trunk: always compiles, not always stable
tags: always compiles, always stable
final testing takes place against a tag before it is then converted into a live release tag.
this way it doesn't matter if the trunk is unstable
You need to primarily make use of "tags" which is nothing but tagging a specific version of trunk to be something stable. tags are generally used to mark releases, which means that the code is stable for the tagged versions.
The way to do it is maintain a trunk to which all members contribute code. If a member wants to develop and test a new feature, he creates a branch, develops his stuff, tests it, then merges into the trunk. When you decide to release the next stable version of the trunk, then you test the trunk code and if found stable then tag that specific version of the trunk as a release version or stable version. Else, fix the bugs in the trunk or in the branch and merge it back to trunk, test the trunk again and if found stable, tag it as stable release. Here, you always consider the tag to be a stable version, the trunk to be development version and your branches to be experimental versions.
But even here, you need to have some quality control on what enters the trunk and what decides a stable version.