The development of Drupal 7 has been unique in many ways. One important milestone was the introduction of unstable releases in October 2008. After ten unstable releases we saw the first alpha release in January 2010. These releases are important because they provide an easy starting point for users for testing and for reporting issues. The more people install and test these releases, the more bugs will be found and the more stable the initial Drupal 7 release will be.

Most people that use these releases however are likely to already know their way around Drupal and to embrace most drupalisms. What greatly increases the variety of people testing Drupal 7 is the private beta testing of Acquia's Drupal Gardens. Some of these beta testers, running a total of over 1000 sites, might not even realize that Drupal Gardens runs the latest official version of Drupal 7 (currently that's Alpha 2) and that by helping test Drupal Gardens they're also testing Drupal 7. This already resulted in a bunch of Drupal 7 bug reports (which are listed on the private forums).

A wise man once said that "[i]f your primary motivation for wanting to be a beta tester is to 'try out' a product before it is released, then you are bound to be disappointed when it turns into a lot of work." Drupal Gardens however makes testing Drupal 7 easy and accessible. Some people might not even realize they're doing it.

A couple of days ago a new unstable release for Drupal 7 was published. One of the many new wonderful features is that installation profiles are now treated as regular modules. This means that you no longer need to learn separate rules, use obscure functions or apply a special Install Profile API. If you know how to write a module, you now know how to write an installation profile. If you want to view a simple example of how this exactly works now, you can take a look at the expert installation profile that ships with Drupal 7.

As Angie mentioned on the dev mailing list:

Install profiles are now basically modules with .install files, .info files to declare dependencies, etc. If you can write a module, you can write an install profile, and you can also do everything from install profiles you can do with modules including use the full Drupal API and write update functions to move from one version to another.

If I remember correctly Starbow was the first to suggest this approach in a post dated about a year ago. It looks like things will work out just fine. Good stuff!