2.0.0 release notes DRAFT
The Aegir team is very pleased to announce the official release of Aegir 2.0.0.
This release deprecates the 1.x branch, marking the 1.11 release as the last one of the 1.x branch. This also marks the "alpha" status of the 3.x development branch and the adoption of semantic versionning for release numbering.
With 2.0, we have improved multi-server support, fixed a lot of issues with SSL and Nginx, Drush 5 support.
We have a very dynamic community of contrib developers, and various projects built atop Aegir. So if you were waiting for Aegir 2 to be stable, easy to install, production-ready, now is the time. The 2.x branch will be well supported as a lot of shops are running it in production already. What are you waiting for?!
1. Major changes in this release
Since our last stable release (1.0) in April 2011, we've done an incredible amount of work. The code size nearly doubled as did the development team and user base, although we still don't clearly know how many installs there are out there.
We can already say that we've been pretty successful at fulfilling our release goals for 2.0 and the 2.0 roadmap. Even though we're missing bits and pieces, especially in X, and Y support is not as robust as we'd like it to be, there's still space for improvements and bugfixes in the 2.x branch, and we'll also start on the 3.0 roadmap once this release is out the door.
- X
- X.a
- X.b
- X.c
- Y
- Y.a
- Y.b
- Y.c
- Z
2. 2.x branch maintenance policy
With the 2.0 release, the Aegir project is adopting the growing standard of Semantic Versionning, which can be summarized as follows:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.
In other words, this is the 2.0.0 release! The next release of the 2.x branch will likely be 2.0.1, unless we ship some major functionality, in which case it will be 2.1.0. In any case, no API change will be done in a 2.x.y release. All core development will now happen on the 3.x branch, which shifts the focus of development to the port of the frontend to Drupal 7 (almost complete).
Note that the 2.x API has already been frozen for some time, since the first release candidate, to be more precise. Major changes to 2.x will not be committed unless they are first tested in 3.x and merged back. We consider it unlikely that major changes will be shipped in the 2.x branch and as soon as the 3.x branch is declared stable, all Aegir operators will be strongly encouraged to upgrade.
The 1.x branch is now deprecated and the 1.11 release will likely be the last release of that venerable branch, unless we need another release to fix the upgrade path to the 2.x branch, but we consider this unlikely. Security fixes or critical issues will not be backported to the 1.x branch.
3. Installing and upgrading
The canonical source of installation documentation is on the community site at:
http://community.aegirproject.org/installing
In a similar fashion, the upgrade documentation is:
http://community.aegirproject.org/upgrading
Within those sections you'll find step-by-step instructions for performing both manual and automatic upgrade processes.
It is still imperative that you read the the upgrade path and version-specific information and follow all version-specific upgrade instructions before trying to run the upgrade script or manual upgrade.
For users coming from the 2.0 betas or recent rc releases, there are unlikely to be any version-specific manual steps required to upgrade, but you should make a habit of reading them anyway just to make sure. No-one likes a nasty surprise!
4. Need help?
If you struggle to install or upgrade your Aegir system, you have a number of options available to you for getting help.
Consult this page for more information: http://community.aegirproject.org/help
Thanks to our awesome community for their help, support and encouragement as always! Enjoy the new release :)
5. API changes
see upgrading/path, copy more important stuff here.
6. Documentation updates
Our documentation initiative to better document the Hostmaster API has progressed nicely. In addition, we'll be launching an updated version of our API site (along the lines of api.drupal.org) shortly, to ease exploring the code-base of the Aegir Project. Much work remains, so you can track progress or help out here.
7. New features
Since this is like a release candidate, we tried to limit the changes to this release to avoid breaking too many things, so not many new features. Of course, since 1.0, there are tons (see above) but this is only since rc5.
8. Bugfixes
We did fix a lot of things however, with the upgrade path and the remaining critical issues.
9. Known issues
Being really open about our project, we have never hidden the fact that some things, sometimes, do not work in Aegir. Our issue trackers are public, and we've made it a point of honor not only to document clearly what is wrong in our releases as soon as we find out about it, but also to reroll new releases when we fix it.
That being said, 2.0 still has a number of issues and design flaws. This is the list of all issues marked "major" in the queue right now. Most issues are now likely to be fixed in the 3.x development branch, and unlikely to be backported unless considered critical (leading to data loss or security issue).
10. The future
While we're very proud of what we've accomplished in Aegir 2.0, we've also been working in parallel to port Aegir to Drupal 7. Aegir 3.0 will begin as a fairly straight-forward port. As such, we'll be releasing our first (pre-)alpha of Aegir 3 shortly. We would like to have a stable Aegir 3.0 release before the release of Drupal 8, to allow for users to transition as Drupal 6 enters its end-of-life phase.
In the 3.x cycle, we'd like to move to Semantic Versioning. This should allow us to add functionality in point releases, so long as they're API compatible. This should allow for more frequent additions of functionality, without having to wait for a full new version release.
Another reason for this change of approach is that we've been discussing a full re-write of Aegir for some time, and would like to do so with Aegir 4. The changes are likely to be fairly drastic, and so we want to be able to keep moving Aegir 3 forward in the mean time. By moving to Drupal 7, we expect to have bought ourselves 2+ years of breathing room within which to accomplish this re-architecture.
When the Aegir project started (back in 2008), the free software options for systems management software were very limited. As a result, we wrote our own code to do things like deploying code, writing configuration files, starting and stopping services, and so forth. Now, as 2014 begins, there are a wealth of tools that perform subsets these functions, each with their own communities supporting them. We are exploring how we might be able to leverage these tools, rather than maintaining our own partial implementations, that will never likely be as robust as these more specialized projects.
We feel that the time is opportune since Drupal 8 will require significant re-writing of the front-end components. In addition, re-writing the backend so completely will allow us to seriously consider moving to a programming language other than PHP; one that would be better suited to the project's long-term goals, such as Python or Ruby.