Drupal 7, which officially drops 7.0 on January 5, 2011, represents a huge leap over previous versions of Drupal as a development framework. With an eye on enterprise-level development, there are countless internal changes to how Drupal functions at its core. For those designers, developers, and administrators who are used to Drupal 6 and looking to begin using Drupal 7, there are a lot of changes to be aware of.
The Drupal community has spent literally years refining the administrative interface. Drupal 7 represents a culmination of these changes. To begin with, the customizable admin bar that follows administrators around is a huge win. Additionally, most users will notice the new overlay system used to help administer most aspects of Drupal without leaving the currently used page. Along with some great new themes (Bartik and Seven), Drupal 7 feels fresh.
So it looks different, but what about the internal changes?
When Phase2 started developing in Drupal 7 several months ago, one of the biggest issues we faced was the state of documentation for D7 API changes. The API changed frequently between dev releases, beta release, and RCs, and keeping up with these changes required knowing where to look for documentation.
For Drupal 7, there are new templates and new ways of displaying content.
The render() function will become a themer's new best friend, even if it's overwhelming at first. This function takes an array (with suitable elements) and converts it into fully formed HTML. This approach allows everything to be kept as data for as long as possible to allow for last-minute changes to alter the output. When upgrading existing themes to Drupal 7, the render() function accounts for the biggest changes.
There are also new templates that need to be considered. There is now html.tpl.php for managing the actual HTML document that your theme will produce, and page.tpl.php has become the portion of the template between the body tags. A themer can now get specific page templates (such as the front page, page--front.tpl.php) without having to duplicate all the unchanging meta data (used for SEO and RDF data) that belongs in the HTML document.
One of the coolest additions is the region template. Regions haven't fundamentally changed, but the addition of region templates (nothing new if you're really familiar with the Zen theme in Drupal 6) makes it really easy to handle special cases for regions. Specifically, this is great for cases when a sidebar needs radically different HTML to display a rail or menu (i.e., region--second_sidebar.tpl.php).
For themers, perhaps the single best beginning reference is Update your theme.
Perhaps you've seen the #d7cx pledge on many project pages, pledging to have a full Drupal 7 release on the day Drupal 7 is released. Perhaps you've made this pledge yourself, or you simply need to maintain some custom modules you've developed.
To upgrade an existing module, unless it's very simple, the best place to begin is by using the Coder Upgrade Module. Provided you've followed standard Drupal conventions, this module will convert a Drupal 6 module to a Drupal 7 nearly-ready version. This is the successor to the Deadwood module.
The Drupal API has changed, and added many new components. The most obvious is the Field API. Any Drupal 6 (or 5) developer is familiar with CCK and the ability it grants to create new content types. This ability is now a part of Drupal core, and the power to manipulate fields and entities is a whole lot easier. There's no more messing directly with CRUD to extend new or existing content types.
For module developers and maintainers, a great source of Drupal 7 module changes can be found at Upgrading modules.
This is more of a reminder than something new, but since Drupal 7 core and contributed modules are still new, there are still plenty of bugs that need squashing. The easiest way to help is to provide patches. For submitting patches, see the Create a patch page.