screeningBee Data Analysis Tools

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Release Compatibility Policy ======
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 [[http://producingoss.com/en/development-cycle.html#release-number-simple-strategy | Producing Open Source Software - Release Numbering]]

====== Release Branches ======
  * Create 1.0.x branch:
<code>
$ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x
</code>
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:
<code>
$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0
</code>
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:
<code>
$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.1
</code>
  * 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:
<code>
$ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x
</code>
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:
  * [[http://producingoss.com/en/release-branches.html | Producing Open Source Software - Release Branches]]
  * [[http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html | Version Control with Subversion - Release Branches]]
screeningBee Data Analysis Tools

User Tools

Site Tools

Page Tools
