Comments (12)
@ciaranmcnulty indeed. even better.
If we go that way, I suggest consider #203 first (that I just created) as behat/gherkin-i18n
would then ship in the new format.
from gherkin.
The obvious thing to do I guess would be to continually bump the major version number, but then behat would need to keep doing the same
Another would be to somehow split out the keywords into a separate repository?
from gherkin.
Another would be to somehow split out the keywords into a separate repository?
that would not help either. If behat/gherkin
is the one depending on behat/gherkin-keywords
, changing the constraint to allow a new major version of behat/gherkin-keywords
would still break projects using behat/gherkin
if they rely on a removed keyword (as they probably won't directly depend on behat/gherkin-keywords
).
from gherkin.
But we could version they keywords similarly to the cucumber versions, and at least when there was a break people would be able to pin back to an older version explicitly
Or we could make gherkin-keywords just a suggest, and throw an exception if it's not present?
from gherkin.
if gherkin-keywords
is an optional dependency of gherkin that gets managed separately in projects using i18n, this would indeed solve this.
If we go this way, I would still include the en
locale in behat/gherkin itself so that things work out of the box for projects not using i18n in their gherkin files. If we only need to manage BC breaks in the en
keywords, it should be fine (they probably don't break the existing en
keywords in each of their major releases, and we will be able to review such changes)
from gherkin.
@aslakhellesoy Can you comment on the likelihood of breaking backwards compatibility in the en
translation of gherkin?
We'd need to communicate to users why their tests stopped working if we went this route, of course
from gherkin.
@stof we could even call it something like gherkin-i18n
in that case
from gherkin.
On the other hand maybe we could make cucumber/gherkin-php
that only contains the translations (and the Dialect objects?) and gets versioned with the monorepo
from gherkin.
That would not help if behat/gherkin
is the one depending on it rather than the project bringing it.
The available translation keywords are part of the public API of a gherkin parser (removing a keyword would make your existing gherkin file invalid if it was using the keyword), so updating to a newer major version of cucumber/gherkin-php
would be a BC break for behat/gherkin
as projects would receive the new keywords without any other opt-in. And so it would still require new major versions of behat/gherkin
.
To me, we have only 3 solutions:
- bump the major version of
behat/gherkin
each time cucumber bumps the gherkin major version (or at least each time it bumps it due to keyword-related BC breaks as we only care about their translations, not about other APIs) - create a separate
behat/gherkin-i18n
package that projects require, so they can choose when the migrate to the new BC-breaking keywords. In this option,behat/gherkin
would require a major version only in case of BC break in the English keywords (we must still ship support for English inbehat/gherkin
otherwise the package is unusable without usingbehat/gherkin-i18n
, which would then justify makingbehat/gherkin-i18n
a requirement, and then we're back at option 1) - not caring about BC breaks in translation updates, shipping them in
behat/gherkin
minor versions (i.e. the current state, except that we were not really updating at all in the past 2 years instead)
from gherkin.
Whatever strategy we took for 2. would also apply to a cucumber/gherkin-php
wouldn't it? We'd need some mechanism (a break?) that prompted projects to directly depend on the new package
from gherkin.
@ciaranmcnulty if behat/gherkin
has a requirement on cucumber/gherkin-php
, then there is nothing enforcing projects to directly depend on them.
That's why my suggestion for 2. is still bundling the English keywords in the main package, so that the parser can still be used (for non-i18n gherkin file) by default, even if behat/gherkin
does not depend on behat/gherkin-i18n
. This solves this issue as a project wanting to parse i18n gherkin files has to depend on the i18n package directly (as nothing else depends on it).
Of course, we would still need a major version bump of behat/gherkin
initially when removing support for i18n without the dedicated package.
And the fact that English is usable without the i18n package also implies that the dialect classes are still part of behat/gherkin
. The behat/gherkin-i18n
package would only provide the translations, not the infrastructure for dealing with a gherkin dialect.
then, having this translation-only package being named behat/gherkin-i18n
or cucumber/gherkin-php
is just a naming thing. but I would prefer avoiding the cucumber/gherkin-php
name for a package shipping only gherkin translations in a composer package. The package name would imply that it is the PHP parser for Gherkin. And that would block the name if we later decide to implement a PHP parser in the monorepo (based on the cucumber generated parsers), while that cucumber/gherkin-php
name would be the perfect match for such parser.
from gherkin.
The obvious thing to do I guess would be to continually bump the major version number, but then behat would need to keep doing the same
Having considered the options I'm leaning towards this. It doesn't hurt much if Behat/Gherkin has a lot of releases, and it's trivial to increase the supported versions in Behat/Behat (in a patch release?) Then users can pin back their Gherkin version if they want to.
from gherkin.
Related Issues (20)
- Comment between tags and scenario is not allowed with v4.7.0 HOT 4
- When creating ExampleNode outline title is never passed to contructor HOT 4
- The Keywords API is based on cucumber gherkin 2 HOT 1
- Examples descriptions not parsing correctly
- Whitespace around language stops detection HOT 1
- TagFilter does not implement cucumber tag expressions
- Missing feature keyword should not error
- Feature description whitespace does not match Cucumber HOT 3
- Comments after tags are captured
- Background and scenariondescriptions not supported HOT 1
- Inconsistent cells count throws low-level error
- Whitespace is allowed in tags
- Non-UTF8 file encodings
- Wrong hash for cucumber releases? HOT 6
- Cucumber update PRs don't trigger CI
- Test our examples against cucumber HOT 3
- Migrate parser to `cucumber/common`? HOT 8
- removed
- TagFilter not checking for empty string
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gherkin.