Expose cucumber-gherkin and cucumber-messages api to make cucumber-ruby not dependent on those anymore

[aurelien-reeves]

cucumber-ruby-core depends on cucumber-gherkin and cucumber-messages. Cucumber-ruby too.

They versions of those dependencies have to be kept in sync.

That is responsible for major or minor version bump without any api change.

For example, if cucumber-ruby-core depends on gherkin 22 but cucumber-ruby still depends on gherkin 20, releasing a new patched version of cucumber-ruby-core will prevent cucumber-ruby to be installed using bundler. Even without any api change.

If cucumber-ruby was using API exposed from cucumber-ruby-core only, new version numbers would be more coherent with semver that stated that only API changes should be responsible for minor or major version bump.

@aslakhellesoy @mattwynne what do you think?

[mattwynne]

I'd like to understand specifically how cucumber-ruby uses those libraries. In theory they are deeper in the dependency graph and so should be more stable than cucumber-ruby-core, so it should not be a problem to depend on them everywhere.

If we are, for example, exposing the message objects via cucumber-ruby's formatter / plugin API, and we introduce a breaking change in the messages protocol, then we can't avoid making a major release of cucumber-ruby too.

[aurelien-reeves]

I'd like to understand specifically how cucumber-ruby uses those libraries. In theory they are deeper in the dependency graph and so should be more stable than cucumber-ruby-core, so it should not be a problem to depend on them everywhere.

The ruby implementation itself should be more stable. But when we release a component, we release all its implementation. That way we have more minor and major version bump than we could have expect if focusing only for ruby.

For example: https://github.com/cucumber/common/blob/main/messages/CHANGELOG.md The last time we had ruby impacted with messages was with 17.0.1. If we would have a new patch fix for ruby, we would actually bring something > 17.1, because the actual version is 17.1.1: a minor version bump, without any impact in the ruby implementation.

If we are, for example, exposing the message objects via cucumber-ruby's formatter / plugin API, and we introduce a breaking change in the messages protocol, then we can't avoid making a major release of cucumber-ruby too.

Yes, API change would still be responsible for new minor or major release. The issue here is for non breaking changes that are also responsible for new minor or major releases because of dependency issues rather than API changes.

But actually, the issue may be more related to libraries with new minor and major version for an implementation without actual breaking changes than cucumber-ruby and cucumber-core both depending on those libraries.

[aurelien-reeves]

Exposing messages and gherkin APIs through core would also help automatic updates of dependencies.

At the moment, if there is an update of messages, a bot cannot automatically update ruby because we would need first to update core, then release it

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two months if no further activity occurs.