The process of working with release candidates is much a more professional
way of releasing software, but much less exciting from a developers point of view. A release candidate becomes the release when there’s no bugs found in it*, which is months after the interesting work is complete.
From my perspective all the interesting work was done months ago, and we’ve just been shaking it down to get it ready for primetime. That said, it’s quite exciting working on a project which has grown from me tinkering in a metaphorical basement, to whole team.
Traditionally someone discovers a bug within about 6 hours of a .0 realease, so don’t be surprised if there’s a 3.1.1 soon after, but that’s us being responsive. We also have some admin features we’d have liked to make it into 3.1.0 which we may add in minor versions, as these will not impact the way data is collected and stored, or the user experience. We figure the Admin user can take a bit more change than the depositors and anonymous masses, so plan features accordingly, with any “culture shock” in the .0 release.
* on that note, I think there is still a bug in some HTML rendering in our new issues tracking interface, but as only Admins see this, and people are clamoring for the stable release, we decided to let it slide. The issues tracker is pretty cool – it uses a new type of plugin to find issues in the repository like duplicate titles, or items described as “in press” that are years old. The underlying code also has fields to describe user-raised issues, like a mini bug-tracker, but in 3.1.0 this isn’t visible to the user intrerface.
One really fun (I’ve been working in OA/library software too long clearly, if I describe this as fun) new feature came out of a passing question from Les Carr, which we tried on our own eprints service. The new way views work allow you to create tag-cloud style links at the top of a view. The more items in the grouping, the bigger the link. This turns out to be quite cool when applied to the authors on a paper. eg.