Retain trailing newline. #6
Conversation
|
The only remark I could give is that the solution should never follow the desire to do a patch release or minor release. I don’t think there can be any debate that this is a breaking change, as it changes the output of the public API, regardless if that change actually impacts someone or not. So logically, this would bump the minor version, not the patch version. I’ve seen some interesting projects being worked on that “take the human aspect out of versioning”. If you test input/output of your program, and one of your changes breaks the test, you’ve got a breaking change and so you release a new major version (unless you are still in a pre-1.0 phase). The problem is that people started associating major version bumps with “marketing releases”, which brings back those human aspects to an otherwise clear-cut decision on what to do after a change. Anyway, getting a bit pedantic here. Love your crate, and obviously whatever you do is your prerogative. But I wanted to give you my 2ct. 👍 |
|
Yep, I agree. I'll plan to hold this back for the time being, release 0.3.1 with the interior newline preservation, then couch this until I have a little more to add for the minor bump. |
During #3, there was some debate about how newlines should be preserved, especially with regards to the trailing newline at the end of the program's output. While the trailing newline may make the test expectations a little more ugly, my feeling is it's more correct when compared to what the `jq` binary itself produces. A difficult decision to make at this point is whether or not this diff should be considered a breaking change, bumping us up to 0.4.x or if it should be a plain bugfix, continuing the current 0.3.x line. Best as I can tell, callers who are relying on feeding the output into a parser such as serde will not see any impact. The only callers who may have been impacted are those who are doing string matching on the raw string. I'm going to sleep on the matter of which digit to bump the version by. I may use this as an opportinity to make some other changes with the opening this creates, perhaps in error handling.
onelson
force-pushed
the
reconcile-newlines
branch
from
aefda83
to
0f3a8bc
Compare
|
Rebased to target the crate name change. |
During #3, there was some debate about how newlines should be preserved,
especially with regards to the trailing newline at the end of the
program's output.
While the trailing newline may make the test expectations a little more
ugly, my feeling is it's more correct when compared to what the
jqbinary itself produces. A difficult decision to make at this point is
whether or not this diff should be considered a breaking change, bumping
us up to 0.4.x or if it should be a plain bugfix, continuing the current
0.3.x line.
Best as I can tell, callers who are relying on feeding the output into a
parser such as serde will not see any impact. The only callers who may
have been impacted are those who are doing string matching on the raw
string. I'm going to sleep on the matter of which digit to bump the
version by. I may use this as an opportinity to make some other changes
with the opening this creates, perhaps in error handling.