This site is a static archive of the Aegir community site. Documentation has moved to http://docs.aegirproject.org. Other community resources can be found on the Contacting the community page.
Skip navigation
HomeAegir HandbookCommunity coordination guideRelease NotesOlder 2.x releases2.0 release notes

Revision of 2.0.0 release notes DRAFT from Tue, 01/07/2014 - 21:21

Help

2.0.0 release notes DRAFT

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

The Aegir team is very pleased to announce the official release of Aegir 2.0.0. This long-awaited release ships with significant stability improvements, Drush 5 and 6 support, subdirectory multisite support, improved nginx support, native views, semantic versionning and much, much more! We unfortunately had to drop support for Drupal 5, as Drush 5 and 6 dropped support for this unsupported Drupal release.

This release deprecates the 1.x branch, marking the 1.11 release as the last one of the 1.x branch. All Aegir users are strongly encouraged to upgrade to the 2.0.0 release. The upgrade has been thoroughly tested and works fairly reliably, except some documented minor issues.

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 have accomplished a significant number of the release goals we set for 2.0, but not all. Here is a broad breakdown of the most important improvements between the 1.11 and 2.0.0 releases:

  • Subdirectory multisite support
    • you can now have different sites in example.com/foo and example.com/bar, a great feature if you do not control DNS, as well as for local development!
  • SSL improvements
    • IP allocation improvement: addresses can be changed, added and removed more easily, and are managed from the front-end now.
    • SSL certificate generation now has saner defaults (e.g. 2048bits)
    • better error handling
  • Drush 5 & 6 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, but Drush 6 or 5.10+ is recommended.
  • Packaging improvements and changes
    • Nginx support in the Debian package
    • now a "native" debian package
    • package name changed: it is now aegir2, aegir2-provision, etc, to avoid overwriting the previous package - note that aegir 1 and 2 can not be installed in parallel
    • hosting and eldir now split back in their own projects on dripal.org
    • using Drupal.org packaging tools to provide a full tarball for the whole frontend, speeding up installs significantly
  • 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
    • improved stability
  • Code refactoring and improvements:
    • now using the Symphony autoloading code
    • fix coding style in a lot of source files
    • improved builtin test suite
  • Frontend improvements:
    • all custom displays ported to Views and VBO
    • nicer frontpage
    • new and improved roles with more useful default permission sets
  • Documentation improvements:

For a more detailed list of new functionalities, bugfixes and API changes, see below.

Some goals of the original 2.0 roadmap have not been accomplished, namely:

  • modular backup, platform and queuing systems - although work has started on Wordpress support, and an overhaul of the Aegir architecture is considered for 4.0, which will affect queuing systems (see below)
  • DNS, PostgreSQL and statistics efforts have mostly stalled
  • clone and migrate optimisations still have to be completed
  • completely automatic upgrades have not been implemented, although the Debian package upgrades are working generally well
Back to top

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

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

Another reason for the change to semantic versionning 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 these functions (e.g. Puppet and Chef, but also Openshift, Docker, etc), 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

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

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

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

  • If /var/aegir is a symlink, it will be destroyed, see issue #2118857 for a workaround.
  • hosting-queued doesn't get properly re-enabled on upgrades, see #2114675 for a workaround.
  • Some upgrades fail with mysterious redirection failures, see #2118061 for details.
  • Some upgrades may loop over one of the update_N() functions, see #2118917 for details and workaround.
  • Upgrading through Debian packages removes the aegir.conf Apache configuration file, dropping all sites, during the upgrade, see #2121263.
  • Ubuntu saucy has some changes in apache config wich breaks Aegir #2155705
Back to top

3. Complete list of changes

Back to top

3.1. 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
  • the '--force' option also allows running tasks that appear to be running in the queue
  • 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
  • deprecate hosting_ip_delete_revision(), dupe of hosting_ip_delete() now that revisions are gone (8 weeks ago)
  • allow running tasks that appear to be running with --force
  • remove deprecated DEBUG flag in debian package
  • #1785624: Some Drupal API changes in D7 (and D8) are not used/respected properly
  • #1945950: Rename provision_drupal_sync_site_back()
  • #1083366: Make the spokes authoritative for files/ and private/ directories
  • #1812338: Refactor sync back
  • a new control file has been introduced in /etc/nginx/basic_nginx.conf to force the nginx configuration to be the "simpler" one (see #1635596: nginx: do not decide the policy for users)
  • #1987026: Move generated platform drushrc.php to sites/all/drush
  • Multiple files can be managed in a single context now (see issue #2000038, issue #1784108)
  • #1034520: Cleanup package instances when deleting sites and platforms.
  • #1830220: Drop support for Drupal 5.
  • #1975086: Move log parsing and status updates to seperate functions and call them from a shutdown function.
  • Pass the entity type when we're sync'ing package instances.
  • Save the platform field when creating a package instance record.
  • Move to individual operation callbacks for VBO tasks.
  • #2022849: Record disable and delete backups in the database.
  • #2031491: Rename SSL permission to be more descriptive.
  • Clean up hosting_node_grants().
  • Add 'administer' permissions for platforms and servers, and allow platforms to be viewed.
  • Update external dependencies.
  • #1283738 by halcyonCorsair, cweagans: Allow other commands to add or alter the directories to be created.
  • remove version pinning in hostmaster, our release process now again needs to modify only one makefile (#2002114)
  • #1986928: Provide 2.x upgrade guidance for services
  • #2099889: More hosting_features checks in _drush_load hooks?
  • #1882708: Unused 'release_id' field in 'hosting_platform'
  • #2012508: hosting_context_name returns '@' if node not found
  • #1283738: Add new hook provision_drupal_create_directories in _provision_drupal_create_directories
  • There is now a registry in the backend of the features enabled in the front-end (in /var/aegir/.drush/drushrc.php) which allows backend components to better determine when they should act.
Back to top

3.2. New features

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

Back to top

3.3. Bugfixes

Back to top

3.4. Other issues

  • #1923552: Rename 'Queue runner settings' tab to 'Queue daemon'
  • #1834036: Add 'hosting platform pathauto' to the .gitignore
  • #1785624: Some Drupal API changes in D7 (and D8) are not used/respected properly
  • #1979496: Update upgrade.sh.txt for Drush 5
  • #1974752: Document old_uri option for provision-deploy
Back to top
Need help?

Documentation

The notebook section provides a way for you to store and share information with your group members. With the book feature you can:

  • Add book pages and organize them hierarchically into different books.
  • Attach files to pages to share them with others.
  • Track changes that others have made and revert changes as necessary.
  • Archive books that are no longer of interest to the group. Archived books can be reactivated later if needed.

The revisions let you track differences between multiple versions of a post.