jerry gay wrote:
On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT
<[EMAIL PROTECTED]> wrote:
On Sat Jun 11 13:08:49 2005, chip wrote:
Short version: Up through version 0.8 or so, we promise to break
everything constantly (but not until we have a good reason). After
that, we will establish version number thresholds below which
individual APIs will not change.
For example, only on a major version change are we allowed to even
consider breaking the embedding API. On the other hand, we may break
pasm somewhat more frequently: humans should only write pir, not pasm,
and it's not against the law to abuse silicon-based life forms.
Has anybody put any thought into this? Do we have any documents or
drafts which address this issue? We are getting close enough to the 0.8
release that's mentioned here as a specific milestone for getting this done.
replace 0.8 with 0.50 or so. we're not close enough to release at 0.8
to worry about this yet.
Change that to 1.0, which is when we'll start guaranteeing API stability.
And, we have discussed it considerably. The most likely scenario so far is:
- Yearly major release (1.0, 2.0, 3.0...), which may contain substantial
API changes.
- Half-yearly minor release (1.5, 2.5, 3.5...), which may contain minor
API changes, and deprecation notices for the next major release.
- Regular (two/three month?) point releases (1.x.x, 2.x.x...) primarily
bug and security fixes, which will contain no API deletions, but may
contain minor API additions, and deprecation notices for the next major
or minor release.
This continues our time-based release policy, which has worked well for
the development release process. Features that don't make it into one
major or minor release get rolled into the branch for the next major or
minor release, so we don't have an insane rush to cram features in just
before a release.
Allison
