Hi Tom (and other MooTools project decision makers),
in other open source projects that I am involved in, there are some
established conventions with version numbers that help to set
expectations for users of those projects. Perhaps something similar
would help establish a sense of consistency for the MooTools
community. Roughly, the conventions are:
* releases are numbered <major>.<minor>.<bugfix>
* <bugfix> releases only fix bugs in a particular <major>.<minor>
release, absolutely no new features and absolutely no API change
* <minor> releases may add new features and wrap up bug fixes, but
absolutely no API change
* <major> releases may add new features, wrap up bug fixes and change
the existing API in an incompatible way.
While I doubt there is anything approaching a standard for release
numbering, I have seen the above used enough that most users of those
projects seem to implicitly understand that jumping from 1.x to 2.x is
potentially disruptive while jumping from 1.x to 1.(x+1) should not be.
If this was applied to MooTools, then the current version would have
been released as version 2.0. Having watched some of the discussions
over the last couple of weeks (and really having to bite my lip in a
couple of cases), I really think if you had chosen 2.0 as the version
number for the new release, it would have eliminated at least some of
that.
Cheers
Paul
On 6-Oct-08, at 2:51 PM, Tom Occhino wrote:
First let me start by reiterating that from now on, we will really
try not to break compatibility. That being said, let me explain that
if a breaking change is necessary to make MooTools the absolute best
framework it can possibly be, we will not hesitate.
