Closed rayjolt closed 4 years ago
As this would be a breaking change, it would need a new major version number to be compatible with semantic versioning. How about the following strategy for migration?
--single-line-tags
and --multi-line-tags
, with multi-line tags being the default.Also, I don't think we should treat version 2.0.0 as a big deal. I'm a fan of releasing early and often, and I don't see a problem with releasing a new major version every few months or so, if we have a good reason to.
I agree that we should make single-line tags the default in v2.0.0. However, we need to settle on the format of tags separated by comments in between, for example,
# comment1
@tag1
# comment2
@tag2
# comment3
Scenario: scenario name
We could reformat this to
# comment1
# comment2
@tag1 @tag2
# comment3
Scenario: scenario name
i.e., group the tags to the last tag's line.
What do you think?
Yes, I think that is a good way of doing it. This allows the finest granularity of comments while still keeping all the tags on one line.
I've started work on a single-line-tags implementation that works as discussed above. The code is working, but it needs cleaning up. Hopefully it should be done today.
@rayjolt I have another implementation at #29. Could you give me your opinion on this implementation?
Ok, I'll have a look now.
Currently, if a node has multiple tags, reformat-gherkin renders them on multiple lines:
However, I believe that multiple tags should be rendered on a single line, like this:
The reason for this is that the majority of Gherkin examples on the internet use single-line tags, and some Gherkin implementations only accept single-line tags.
Here are the projects I have investigated, and and how they deal with tags:
There are more Gherkin implementations that I haven't checked, but I believe the trend to use single-line tags is clear.