Yesterday evening, the Apache Maven project announced the first milestone release of the 2.1.0 (2.1.0-M1 is the actual version name). I highly recommend downloading your copy today, from the Apache Maven website.
This release is the culmination of development work going back beyond last May, and a release process that produced its first release candidate (RC) build for testing on July 18, two months to the day before I was finally able to push the 2.1.0-M1 binaries out to the download page, and announce the release publicly. In that time, the code has undergone some important revision to make it faster and more stable. Looking back, there are some interesting statistics associated with this release, mainly because they highlight a marked difference between the two most recent Maven releases - 2.1.0-M1 and 2.0.9 - and all those that came before. Here are a few of those statistics.
When we started the release process on July 18, we had 41 issues assigned to that Fix-For version in JIRA; when I sent out the announcement to the mailing lists last night, we had closed 70 issues. That's 29 issues that came up during the release-testing process, and were debugged, tested, and resolved, leaving the code more stable than it had been previously. Since July 18, I've personally pushed out 17 release candidates, with an average of 1.71 (we'll call it 2) issues fixed per RC, and about 3.5 days in between RCs on average.
We're all very excited about this release, and I'm very confident that this will be the most stable version of Maven you've used to date. Please give it a shot; you'll be sorry if you don't!
Now, for anyone interested in why this release is called '2.1.0-M1' and not '2.0.10', please read below the fold:
The release of version 2.1.0-M1 marks an important shift in the development strategy here at Maven. Not only is this the second release with an extensive release-testing phase beforehand - which is vastly improving the stability of our releases, for obvious reasons - but it's also the first release of Maven to (formally) move beyond the tight constraints of the 2.0.x version series. Previously, Maven was locked into a sort of dual development mode, where only the lowest-risk bugfixes were introduced to the 2.0.x series, and almost all new development was happening on what we were calling the 2.1 or trunk code. With this release, our development strategy has changed. Now, Maven's development strategy centers on three main goals: regression fixes for the 2.0.x code; low-risk, formally planned features and implementation improvements for the 2.1, 2.2, ..2.x code; and more aggressive subsystem redesign and reimplementation efforts going on in the 3.x code.
There's a danger of getting into a confusing version-soup scenario here, but I'd like to briefly explain the purpose of each development effort. First, with the 2.0.x version series, we're planning to do only regression fixes and put it into end-of-life mode soon. We're starting to run into issues where fixing one regression causes another, and the only good way out involves taking on quite a bit of extra implementation risk...and possibly jeopardizing what stability we have. This is actually why the most recent release is 2.1.0-M1, not 2.0.10 (which is what it started out to be). During the course of fixing issues for the release, we began to recognize the need for some relatively large, risky changes in order to avoid the aforementioned contradictory regression problem. Yet we realized that these code fixes were simply too aggressive for a 2.0.x release, and carried with them more risk for instability (because of the quantity of new code) than we were willing to introduce for 2.0.10.
For this purpose, we have decided to rename the old 2.1/trunk code to 3.x, to make room for a new, intermediary version series. At this point, the 3.x code had already undergone some really significant changes related to embedding, project building, plugin loading, and more. Therefore, these intermediary versions were meant to provide stepping stones for the users, between 2.0.x and 3.x, where new features and reimplementations could be introduced gradually. As part of this effort, we're creating release plans for each minor version release, which will be backed up by design documents and JIRA issues (for tracking in release notes). Each major introduction will constitute a milestone in the release cycle, with the run-up to the final release being another of the release-testing processes that we've just been through.
For more information on the release plans we're currently working on, see the Maven 2.x page on Codehaus Confluence.
Reading through the archives of the Maven mailing lists, you'll no doubt come across mention of the by-now-mythical Maven 2.1; these discussions pertain to what is now Maven 3.x, which as I speak is shoring up nicely for a push to its own first milestone release. This code forms the basis of the IDE integration you're probably using, possibly through Eclipse, via the m2eclipse project or Netbeans, via the Mevenide project. I'm sure this version switch will create a certain amount of confusion, but I'm also sure that all will become clear when the releases start rolling out.
It's an exciting time here at Apache Maven. Keep an eye on the project, and I think you'll see some unprecedented progress over the next few months.
Written by Tim OBrien
Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to Fortune 100 companies take a more strategic approach to adopting and evaluating technology and managing the risks associated with change.
Explore All Posts by Tim OBrien