Closed nicerloop closed 2 years ago
Between Cucumber 2, Cucumber 4, Cucumber 5 and Cucumber 6, there were significant API changes each time; not everyone is/was able to upgrade Cucumber each time. That is why.
In fact, I just tried to upgrade serenity-cucumber to cucumber 7.0.0-RC1, and I found cucumber dependencies inside serenity-model. Is that expected, and does it not constrain serenity as a whole on a certain cucumber-jvm version?
The following classes have direct references to cucumber classes which have moved and changed between cucumber 6 and 7: net.thucydides.core.model.Rule net.thucydides.core.model.RuleBackground net.thucydides.core.requirements.reports.cucumber.RenderCucumber
Yes, Serenity depends on the Cucumber version, particularly since the Cucumber API changes so much each major release.
So why have the cucumber version artificially exposed in the serenity-cucumberX module, when it is not possible to use any other version than the one used inside serenity? Should not the serenity-cucumber module be integrated with the various other modules as it effectively does not have a separate life cycle nor dependencies ?
The was done for historical reasons.
Could it be re-integrated into serenity-core repository?
serenity-cucumber6 does not have the git tags for the latest releases either, it could benefit form the general serenity life cycle.
It's never been part of serenity-core, and it would be a lot of work to put it there.
Why do you explicitly name cucumber version in artifact and repository name? serenity-cucumberX is deprecated when serenity-cucumberY is out, and cucumber versions change quite frequently.
cucumber-jvm 7 is currently in RC1, and would promptly require a new serenity-cucumber7.