Skip to content

[Console] allow answer to be trimmed by adding a flag #32707

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

[Console] allow answer to be trimmed by adding a flag #32707

wants to merge 1 commit into from

Conversation

phil-davis
Copy link
Contributor

@phil-davis phil-davis commented Jul 24, 2019

Q A
Branch? 3.4
Bug fix? maybe - I can't get at the real answer string with leading/trailing spaces ;)
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets none
License MIT
Doc PR symfony/symfony-docs# (to do if backport PR is allowed)

According to #23210 (comment) we add a new flag in the Question class to be able to not trim the answer.

This is a "backport" request for #31626 - the code is completely backward-compatible, any existing use gets the answer trimmed. So this setTrimmable(false) ability would only come into effect if someone modifies their code to use it.

I am asking if it is OK/possible to implement this in the 3.4 branch. I realise that this can be considered a "new feature" and so with semver the version should be bumped to 3.5.0 for a "new feature" that is backward-compatible. And I suspect that 3.5 is no longer allowed to happen. But maybe it could also be called a bug, because without this change there is no way to know that the user's answer has leading/trailing spaces.

@chalasr
Copy link
Member

chalasr commented Jul 24, 2019

I'm sorry, but this is a new feature which will be released in the next minor version, it cannot be backported, as per semver.
As you said, it expands the public API and, in order to be be used, requires code changes.
Answers are trimmed by design and that will stay the default behavior in 4.4. Changing that in a patch version would be a BC break.

@chalasr chalasr added this to the 3.4 milestone Jul 24, 2019
@phil-davis
Copy link
Contributor Author

I was "hoping" this could be considered a bug - the caller does not (and is not able to) get the full "real" answer back from the end-user, and this change provides an optional way for the caller to get the full answer, without breaking the behaviour of any existing calls. Anyway, I understand if it cannot be classed as a "bugfix".

That means that this optional not-trimmed behaviour will not be possible to use until after 4.4 is released.

@phil-davis phil-davis closed this Jul 24, 2019
@phil-davis
Copy link
Contributor Author

Hmmm - I was fixing code for pre-PHP7 support, at least to see if I can make CI pass with the older PHP.
When I force-pushed, this PR got closed and there is no "open" button to re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants