community.aegirproject.org

2.0.0 release notes DRAFT

Tagged:
Updated by ergonlogic on 01/07/2014 - 20:03
AddedChangedDeleted

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.

Note that those release notes collates a lot of the changes already mentionned in previous release notes for alpha/beta/rc releases.

1. Major changes in this release

Since th 1.0 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.

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.

  • SSL improvements:

  • Drush 5 support

    • includes better support for archive-dump command
    • means we also drop the dependency on drush make 2.3, now included in Drush 5
    • support for Drush 4 has been dropped, the minimum version is now 5.5

  • Debian package improvements and changes

    • Nginx support in the Debian package
    • now a "native" debian package
    • package name changed: it is now aegir2, aegir-provision2, etc, to avoid overwriting the previous package - note that aegir 1 and 2 can not be installed in parallel
  • Nginx improvements:
    • fixed support for nginx 1.3 and newer
    • better defaults for caching
    • SSL and Nginx are now officially supported (not marked as "experimental")
  • New modules:
    • the hosting-queue-runner module is now merged into core as hosting-queued
    • "pack" module, designed as a lightweight replacement to the "cluster" module, now available as an experimental extension
  • Hosting-queued improvements
    • run with a lower priority ("niced")
    • improved portability and reliability of startup script
    • enabled by default in the Debian package
  • Code refactoring and improvements:
    • now using the Symphony autoloading code
    • fix coding style in a lot of source files
    • improved builtin test suite
    • eldir is split in its own module again, allowing for porting it more easily to Drupal 7
Back to top

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.

Back to top

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!

Note that you should upgrade to the latest 1.x release (currently: 1.9) before attempting the upgrade to 2.x. This is especially important if you are running a pre-1.0 release (poor you!).

Back to top

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 :)

Back to top

5. API changes

Those changes are, as usual, more explicitly documented in the upgrade path documentation.

  • hosting-task now needs a --force argument to run a non-queued task
  • functions that were deprecated in 1.x are now removed
  • the email and client_email database fields are now removed from client and site node types
  • numerous changes to the IP allocation and SSL management code
Back to top

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.

Back to top

7. New features

In addition to the "major changes" mentioned above, the following should also be noted.

Back to top

8. Bugfixes

Back to top

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

Back to top

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.

Back to top