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 - 20:22

Help

2.0.0 release notes DRAFT

Tagged:
Updated by ergonlogic on 01/07/2014 - 20:22
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.

  • subdir!

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.

  • 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!
  • SSL improvements:
  • 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
  • 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 modules
    • 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
  • 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
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. 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

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

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

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

7. 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.
    Back to top

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

    9. New features

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

    Back to top

    10. Bugfixes

  • #2110057: Key used for signing debian package has expired
  • #1635628: do not talk about a makefile if installing over an existing platform
  • #2103173: Provide an example of saving data to a site context
  • #2109637: upgrade.sh script fails to checkout 6.x-2.x
  • #2085077: Invalid argument supplied for foreach() hosting.ip.inc:39
  • #2102341: Differentiate between a feature being disabled vs absent
  • #2029799: Error deleting a platform: Call to a member function succeed() on a non-object
  • #1971348: Site aliases get chopped if longer than 50 characters
  • #2071317: Incorrect SSL IP is deployed to servers in a web pack
  • #2098289: Backup task does not detect failed database dump
  • #2098389: subdirs kicks in even when subdirs module is disabled.
  • #1189576: can't disable the DNS service from the frontend
  • #1931000: Missing drush backend output in frontend log
  • #2077793: Queue daemon collecting quotes
  • #2097689: clean_urls don't work well with subdirectory
  • #2097363: Add site spins forever
  • #1387578: hosting_queues_cron_cmd makes unwarranted assumptions about bash availablility
  • #2084963: SSL vhost does not respect Alias redirects
  • #2061509: List of platforms is no longer updated to match install profile clicked at node/add/site
  • #2046783: Task dialogs won't open after clearing the cache
    • Back to top

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