This policy is adapted from the numbering system used by the APR project (see http://apr.apache.org/versioning.html).

• Changes to the micro number only (that is, changes within the same minor line) must be both forward- and backward-compatible. That is, the changes should be bug fixes only, or very small enhancements to existing features. New features should not be introduced in a micro release.

• Changes to the minor number (that is, within the same major line) must be backward-compatible, but not necessarily forward-compatible. It's normal to introduce new features in a minor release, but usually not too many new features at once.

• Changes to the major number mark compatibility boundaries. A new major release can be forward- and backward-incompatible. A major release is expected to have new features, and may even have entire new feature sets.

These rules do not apply to pre-1.0 releases (e.g. release 0.1.0, 0.1.1, etc..), in order not to hamper early development too much.

For more details see Producing Open Source Software - Release Numbering

• Create 1.0.x branch:

$ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x

The same minor line, i.e. the same branch, will be used for all the micros releases in that line.

• Tag a snapshot of the branch, when the release branch is stabilized and ready:

$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0

That tag now represents the exact state of the project's source tree in the 1.0.0 release (this is useful in case anyone ever needs to get an old version after the packaged distributions and binaries have been taken down).

• The next micro release in the same line is likewise prepared on the 1.0.x branch, and when it is ready, a tag is made for 1.0.1:

$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.1

• Repeat for 1.0.2 and so on.
• When it's time to start thinking about a 1.1.x release, make a new branch from trunk:

$ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x

Maintenance can continue in parallel along both 1.0.x and 1.1.x, and releases can be made independently from both lines.

For more details see:

• Producing Open Source Software - Release Branches
• Version Control with Subversion - Release Branches