If you read the Rakudo #17 release announcement carefully, you'll see a curious note:
Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github.
Though Rakudo produces monthly releases (as does Parrot), the pace of development is so fast that Rakudo #17 (released a week ago) doesn't represent Rakudo very well as it exists today. When someone like Jonathan can close ten bugs in an eight-hour day, or a simultaneous change to Parrot and Rakudo can make 1000 spectests suddenly pass for the first time, or a two-character change to Parrot provides a 6.5% runtime performance improvement, a month-old Rakudo release seems ancient in comparison.
Adam Kennedy asked a valid question, however. "Given the recommendation that interested parties track your repository, why bother making releases?"
There are several reasons.
Helping Users
Users benefit from regular releases.
If they want to use the software -- take advantage of new features or bugfixes -- they can do so without having to manage checkouts. Though the project may keep its trunk as stable as possible, it's not always perfect. Trunk represents a work in progress. A release is a stable point the developers believe will work well for regular users.
An official release is much easier for distributions and packagers. If users can get binary releases on a regular basis, they don't even have to know how to configure and build the software to take advantage of new features or bugfixes.
A well-managed official release is easier to upgrade to if the delta between releases is small. I recently helped migrate a server from an ancient Red Hat 7 installation to a modern Ubuntu version. We had to recreate almost everything; little besides user data copied over directly. Now we can keep the server up to date with two simple commands once a week. Sometimes the changes are greater than others, but for the most part, it's transparent and easy.
Helping Developers
A release gets wider distribution and testing than a snapshot or trunk (in the same way that trunk gets more testing than branches). Bug reports, IRC and mailing list traffic, and even commits increase in the days leading up to and following a release.
Regular releases provide an incentive to keep quality high. Packaging, testing on exotic platforms, and documentation tend to suffer first when there's too much to do. If your release process requires you to perform some routine work, you'll do it when the release is near. (Of course if you have irregular releases, this busywork can seem overwhelming -- which is why some projects slip their releases continually.)
Regular releases require you to keep your trunk stable and releasable. Not only does this help you produce the next release on time, but it prevents some of the madcap scrambling that can occur if you need to make an emergency release. Hopefully you never have to do this, but the confidence that comes from knowing that a dozen people could produce a release with an hour or two of notice is electrifying.
Regular releases also require you to work in small pieces. Large branch merges can destabilize the trunk for days or weeks. If you can't avoid them altogether, there's a natural time for them to merge: just after a release. Branches that haven't seen activity in a couple of release cycles seem old and crufty. (There's a reason they haven't merged.)
A regular release cycle produces a measurable cadence. You can graph the commit rate to various parts of Parrot on a calendar. Larger or deeper changes occur just after a release -- there's pent-up demand, and much of Parrot's major progress has occurred in this timeframe. Smaller features merge in the next couple of weeks. The test suite and documentation get reviewed a few days before a release.
Regular releases expose problems in the project. Perhaps your test server is inadequate and you can't get results when you need them. Perhaps one section of the code depends on the attention of someone who has no free time lately. Perhaps only one person has access to your web site to update the notice. You will discover these problems -- and have a chance to fix them before they're catastrophic.
Helping The Project
A project that never releases software looks dead. That may not be true, but perception is important.
Regular releases -- especially on a predictable schedule -- demonstrate that your project takes its reputation seriously. (Please don't assume that I'm implying the converse. You give your users the option to use the best code you have produced at regular intervals. They don't have to upgrade, but they have the option.
Regular releases demonstrate that you care about your project. (Again, please read a disclaimer about the converse here.)
Regular releases keep your project in the news. As boring as releases should be, they're still newsworthy. What's changed? What new feature is available? What's better?
Regular releases attract new users and developers. Our regular committer count has jumped since we started performing regular releases. Our development pace has quickened. We turned around a floundering project and injected new life into it.
People still have doubts that we can achieve our audacious goals, but every month that we release a new stable version of our software that's better than every previous month, we demonstrate that we know how to produce modern software.
Couldn't agree more on importance of regular releases. It's amazing how much time you can waste when the release date is miles away. It's counter-intuitive, but the closer a release date, the easier it is to hit (so long as you can de-scope sensibly).
Having said that, setting up your project to do regular releases is hard. It takes a while to get everyone in the right mind-set. It's much easier to come up with a list of reasons why you *can't* do regular releases, and I think that's why a lot of projects (OSS and the rest) don't end up doing it, even if they want to.