Message-ID: <387550104.107.1432895886219.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_106_749029374.1432895886218" ------=_Part_106_749029374.1432895886218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Since Groovy 2.0.0 we follow the scheme as described in http://semver.org/<= /a>. This means the next minor version after 2.0.0 is 2.1.0, the first bugf= ix version after 2.0 is 2.0.1 and the next major version will be 3.0.0.
Before Groovy 2.0.0 we followed a version scheme where we have X.Y.Z, wh= ere X.Y is the major version, and Z the minor version. Bugfix versions wher= e not really done, you had to upgrade to the next minor version for that. S= ince Groovy 1.0 we incremented only the Y for a new major version. The incr= ement of X we wanted to leave for a very big breaking change, like a new MO= P. The last major version in these scheme is 1.8(.0), 1.8.1 is the first mi= nor and bugfix version. The major versions in the past using this scheme ar= e: 1.8, 1.7, 1.6, 1.5, 1.0. Each of them having around 10 minor/bugfix vers= ions.
The official major version is the current major version that should/can = be used by the developers if they are not bound to a specific major version= .
Here we indicate a former major version's bugfix release.
That depends on the users. Let's say we have X in maintenance and Y is t= he official major version, then if a new major version Z is released, Y goe= s into maintenance. Usually we make one or two more bugfix releases for X a= nd then we discontinue it, unless there are strong requests to have certain= things fixed for users that can absolutely not upgrade.