7.0.0 candidates

[davidjgoss]

Discussion of what needs to be done before cutting a 7.0.0 release. There is a milestone created which concrete issues and PRs can be linked to once they are agreed here.

TypeScript

• Various fixup tasks (Typescript tasks #1269)

Gherkin & Messages

• Minimal support for Rule in out-of-box formatters (format: add support for gherkin rule/example syntax #1273)
• Change messages output to NDJSON instead of binary (format: change message formatter to output NDJSON instead of binary #1295)
• Validate message output with CCK, use latest Gherkin, messages etc (update gherkin etc, validate against cck #1318)
• Mark the built-in JSON formatter as deprecated (show a warning at runtime?) (Deprecate JSON formatter #1249)

Other Breaking Changes?

Do we take the opportunity to make some other breaking changes?

• Make CLI args case consistent (see cli: --retryTagFilter case inconsistent with other args #1291)
• Publish to npm under @cucumber/cucumber in line with other packages (see build: scoped package name #1411)
• Change to how custom formatters are loaded to support external packages (see Load custom formatter by relative path only if it begins with a dot #1413)

[davidjgoss]

cc @charlierudolph @aslakhellesoy

[charlierudolph]

@aslakhellesoy I looked at the compatibility kit a bit and don't see the binary the readme mentions to actually perform the check.

[davidjgoss]

@charlierudolph @aslakhellesoy I got something started for CCK validation here:
#1318 (still very WIP, need to sort out making uris, ids and clock predictable).

Most of the differences are because things have moved on since gherkin 9 and messages 8 which we are depending on right now. Do we want to try and bring it up to the latest gherkin and messages before doing a 7.0.0 release? I'm happy to give that a go if it's the right thing to do.

Also I think the CCK has quite a few changes that aren't yet published in the npm package https://github.com/cucumber/cucumber/tree/master/compatibility-kit/javascript.

[charlierudolph]

Upgrading gherkin / messages works for me. An long as cck if itself versioned and suppose to work with specific gherkn / messages that should be fine.

[davidjgoss]

Still working through these changes.

@mpkorstanje @vincent-psarga are you able to do a release of the JavaScript CCK package with the latest changes?

[mpkorstanje]

I wasn't aware those were released. If nobody else gets to it before the end of this week I'll give it a stab.

[vincent-psarga]

@davidjgoss what do you exactly mean by a release of the CCK ? For Ruby for example, we don't package the CCK as a gem, we run the feature directly from the mono-repo against the code of cucumber-ruby in its branch.

You can see in the config.yml of cucumber-ruby how each build validates the CCK.
That said, we use a tagged version of the mono-repo, usually the one based on the latest cucumber-messages release.

[davidjgoss]

@vincent-psarga the JS version of CCK has been packaged up and published to npm - the current published version 1.0.0 is a few months old though https://www.npmjs.com/package/@cucumber/compatibility-kit

If the setup is already there for it, I think using CCK as an npm package would be the cleanest way for us to work with it

(I'm not blocked on this right now as I have copied the content from the monorepo for the time being)

[davidjgoss]

Now that the cucumber org has control of the @cucumber scope on npm, do we want to rename the package to @cucumber/cucumber for the upcoming release?

[aslakhellesoy]

Yes, I think we should release as @cucumber/cucumber going forward!

[davidjgoss]

Per #1428 we have some confusion because of the state of master vs last published version.

Would it be worth doing a “soft” 7.0.0 release and then publicising a closely-following 7.1.0 that includes the reports stuff?

[davidjgoss]

@charlierudolph @aslakhellesoy do we feel ready for 7.0.0? We do have #1416 open still