-
Hi, I really want to use hurl a lot and everywhere where I can. One big hickup was now version 4.0.0. Instead of breaking the jsonpath. Would it not be a good idea to hide the old way jsonpath behaved behind a feature flag? Then as a user you can choose which one you want, since it is not clear what the specification really is... Normally I am against having a "old" feature behind a feature flag but here both ways would have been useful. This is really a idea for json path and other asserts or captures. Wjat do you think? Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hi, generally we're trying to not make breaking changes. For instance, we've deprecated some keyword a while ago (like In this case, we think the change was rather "simple" for users: in some case, instead of a value, there is a collection now. You can then use Using a feature flag would not have help because you've still to support it in the code (besides the fact that having a feature flag on a cli is not widespread). Also users using this flag would still have problem the time we remove the flag. So it's a tough decision, we're aware of it! This time, we've favoured the code (and us maintainers ultimately!) |
Beta Was this translation helpful? Give feedback.
Hi, generally we're trying to not make breaking changes. For instance, we've deprecated some keyword a while ago (like
HTTP/*
in favour ofHTTP
) but we're will supported them displaying deprecation warning. Doing so made the burden on the maintainers and the code. Introducing breaking changes make the burden on the user.In this case, we think the change was rather "simple" for users: in some case, instead of a value, there is a collection now. You can then use
nth
filter to get the value back. In this case, we've favoured the implementation.Using a feature flag would not have help because you've still to support it in the code (besides the fact that having a feature flag on a cli is not…