Revision of 2.0 release notes DRAFT from Mon, 01/06/2014 - 20:21

The Aegir team is very pleased to announce the official release of Aegir 2.0. While it's been a mostly "open secret" that most of our releases are production ready, this one has been tested through no less than 10 alpha, beta and candidate (RC) releases.

Now onto the release. This actual release isn't much different from the recent release candidates. However, since this is our first major release in a long time, we figured it would be important to outline how things have changed since Aegir 1.0.

With 2.0, we have X, Y, Z and we have a very dynamic community of contrib developers, and even 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. API changes, documentation, 1.x maintenance policy and 2.0

The API changes since 1.0 are too numerous to list here. However, we are now committed to maintain the whole 2.x series with a stable API. There will be no change in the existing API, although we may add in some stuff if it is really necessary. All future API changes between 2.x and 3.x will be clearly defined so that third party modules can be supported.

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.

Major changes to 2.x will not be committed unless they are first tested in 3.x and merged back. We will however keep the branch opened for documentation fixes and non-invasive changes like performance enhancements and cosmetic changes to the frontend. Major problems and "AegirWTF" may also be corrected in the 2.x branch, after a shakedown in the 3.x branch.

From now on, major development will take place in the 3.x branch. The roadmap for that branch is ambitious but we'll tackle things one at a time, again on feature branches for major changes so that even that branch will stay stable throughout its development cycle. We will keep making stable alpha releases for your testing pleasure.

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. 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.

6. Bugfixes

We did fix a lot of things however, with the upgrade path and the remaining critical issues.

7. 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 suffers from a number of significant issues and design flaws. This is the list of all issues marked "major" in the queue right now. Some of those issues can be fixed within the 2.x branch, some can only be fixed by refactoring, and so they will be fixed in 3.x, or beyond (see 'The future', below.)

8. 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.