|
| 1 | +# Releasing Guidelines for Cucumber Godog |
| 2 | + |
| 3 | +This document provides guidelines for releasing new versions of Cucumber Godog. Follow these steps to ensure a smooth and consistent release process. |
| 4 | + |
| 5 | +## Versioning |
| 6 | + |
| 7 | +Cucumber Godog follows [Semantic Versioning]. Version numbers are in the format `MAJOR.MINOR.PATCH`. |
| 8 | + |
| 9 | +### Current (for v0.MINOR.PATCH) |
| 10 | + |
| 11 | +- **MINOR**: Incompatible API changes. |
| 12 | +- **PATCH**: Backward-compatible new features and bug fixes. |
| 13 | + |
| 14 | +### After v1.X.X release |
| 15 | + |
| 16 | +- **MAJOR**: Incompatible API changes. |
| 17 | +- **MINOR**: Backward-compatible new features. |
| 18 | +- **PATCH**: Backward-compatible bug fixes. |
| 19 | + |
| 20 | +## Release Process |
| 21 | + |
| 22 | +1. **Update Changelog:** |
| 23 | + - Open `CHANGELOG.md` and add an entry for the upcoming release formatting according to the principles of [Keep A CHANGELOG]. |
| 24 | + - Include details about new features, enhancements, and bug fixes. |
| 25 | + |
| 26 | +2. **Run Tests:** |
| 27 | + - Run the test suite to ensure all existing features are working as expected. |
| 28 | + |
| 29 | +3. **Manual Testing for Backwards Compatibility:** |
| 30 | + - Manually test the new release with external libraries that depend on Cucumber Godog. |
| 31 | + - Look for any potential backwards compatibility issues, especially with widely-used libraries. |
| 32 | + - Address any identified issues before proceeding. |
| 33 | + |
| 34 | +4. **Create Release on GitHub:** |
| 35 | + - Go to the [Releases] page on GitHub. |
| 36 | + - Click on "Draft a new release." |
| 37 | + - Tag version should be set to the new tag vMAJOR.MINOR.PATCH |
| 38 | + - Title the release using the version number (e.g., "vMAJOR.MINOR.PATCH"). |
| 39 | + - Click 'Generate release notes' |
| 40 | + |
| 41 | +5. **Publish Release:** |
| 42 | + - Click "Publish release" to make the release public. |
| 43 | + |
| 44 | +6. **Announce the Release:** |
| 45 | + - Make an announcement on relevant communication channels (e.g., [community Slack]) about the new release. |
| 46 | + |
| 47 | +## Additional Considerations |
| 48 | + |
| 49 | +- **Documentation:** |
| 50 | + - Update the project documentation on the [website], if applicable. |
| 51 | + |
| 52 | +- **Deprecation Notices:** |
| 53 | + - If any features are deprecated, clearly document them in the release notes and provide guidance on migration. |
| 54 | + |
| 55 | +- **Compatibility:** |
| 56 | + - Clearly state any compatibility requirements or changes in the release notes. |
| 57 | + |
| 58 | +- **Feedback:** |
| 59 | + - Encourage users to provide feedback and report any issues with the new release. |
| 60 | + |
| 61 | +Following these guidelines, including manual testing with external libraries, will help ensure a thorough release process for Cucumber Godog, allowing detection and resolution of potential backwards compatibility issues before tagging the release. |
| 62 | + |
| 63 | +[community Slack]: https://cucumber.io/community#slack |
| 64 | +[website]: https://cucumber.github.io/godog/ |
| 65 | +[Releases]: https://github.com/cucumber/godog/releases |
| 66 | +[Semantic Versioning]: http://semver.org |
| 67 | +[Keep A CHANGELOG]: http://keepachangelog.com |
0 commit comments