Yep, sorry for the inconvenience, we're trying our best to avoid steps
like 1.11 -> 1.2 in the future and if such huge changes happen again
it will be a new major release. Furthermore we're now adding bugfix
releases so patches are getting pushed out earlier.
Jan
On Oct 8, 2008, at 14:50, Paul Spencer wrote:
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.
--
my blog: http://blog.kassens.net
