Serenity 1.1 (1.1.1)
Brand-new Serenity release with bug fixes plus new features, including fully-integrated feature coverage reporting and the ability to include both manual and automated tests in the reports.
Releases
Historical records of Serenity BDD and Thucydides software releases, including version numbers and key changes.
This page lists notable Serenity BDD and Thucydides releases. Version numbers, dates, and download sources are taken from the project blog.
Brand-new Serenity release with bug fixes plus new features, including fully-integrated feature coverage reporting and the ability to include both manual and automated tests in the reports.
Release post covering Serenity 1.0.42 alongside the new Timeout API.
A new Serenity BDD release announced on May 3, 2015 followed this core line.
New Thucydides release from the pre-rebrand project timeline.
Earlier Thucydides release documented on the blog.
| Date | Project | Version | Notes |
|---|---|---|---|
| July 27, 2015 | Serenity | 1.1 (1.1.1) | Fully-integrated feature coverage reporting; manual and automated tests in one report. |
| May 3, 2015 | Serenity BDD | — | A new release of Serenity BDD announced. |
| March 20, 2015 | Serenity | 1.0.42 | Paired with the new Timeout API. |
| March 9, 2015 | Serenity Core | 1.0.38 | Core library release. |
| July 10, 2014 | Thucydides | 0.9.260 | Pre-rebrand release line. |
| March 7, 2014 | Thucydides | 0.9.235 | Earlier release documented on the blog. |
Release artifacts are published through the standard distribution channels listed on the blog.
Release history pages give development teams a clear, chronological view of how a testing framework has grown, matured, and adapted to new demands. By tracking each version in one place, readers can quickly see when major features arrived, how reported bugs were resolved, and which improvements shaped the current state of the tool. A well-organized releases page also helps newcomers understand the pace of innovation and the kinds of changes that tend to appear between major milestones, providing useful context before they adopt the framework for their own projects and decide which version best matches their workflow, tooling, and long-term maintenance strategy.
Beyond simple version numbers, a thoughtful releases page highlights the themes and priorities of each iteration. Entries often emphasize new reporting capabilities, deeper integration with popular test runners, or refined support for behaviour-driven development practices such as BDD and living documentation. Readers can trace how the project gradually introduced richer coverage metrics, more flexible configuration options, and stronger handling of complex acceptance criteria, all of which reflect the evolving expectations of teams that rely on automated checks to validate real user behavior rather than just isolated code paths.
Bug fixes and stability improvements deserve attention as well, since they reveal how responsive maintainers are to community feedback. Each release summary typically balances exciting new features with quiet but essential corrections, such as clearer default values, more predictable wait behavior, or smoother handling of timeouts during slow test execution. By reading across multiple entries, users can build confidence that recurring issues are being addressed, and they can plan upgrades knowing which areas of their test suites are likely to benefit from the latest refinements without requiring significant rework or retraining for the engineers who maintain them.
Release notes also serve as a bridge between documentation and real-world usage, illustrating how abstract concepts translate into practical results. Mention of features like feature coverage reporting, mixed manual and automated test reporting, or improved integration with project management tools helps readers visualize how their own reporting dashboards might evolve. These descriptions encourage teams to revisit their current test organization strategies, consider adopting new reporting structures, and explore how richer living documentation can support stakeholders who need accessible evidence that acceptance criteria are consistently met across releases.
Finally, an effective releases page supports long-term planning by signaling where a project is headed. When entries describe expanded plugin support, broader browser capabilities, or new ways to structure requirements and scenarios, they invite readers to imagine upcoming possibilities for their own pipelines. Teams can anticipate training needs, identify upcoming breaking changes, and align their internal roadmaps with the direction of the framework, turning the simple act of browsing release history into a strategic exercise that informs both immediate upgrades and longer-term decisions about tooling, collaboration, and overall quality assurance practices across the organization.