[Discuss] How breaking should NEST 5.0 be?
See original GitHub issueNEST 2.x
was a pretty heavy breaking major release, with 5.0.0 alpha’s around the corner we should decide beforehand how backwards compatible we want to be for our next major release.
e.g the TermsQuery
no longer supports MinimumShouldMatch
and DisableCoord
, do we simply remove these from our client or mark them as obsolete?
That is a pretty easy to support backward compatible change but what do we do for more complex cases?
I’m +1 on removing these and starting from 5.0 maintain a stricter [Obsolete] observance of deprecated properties in Elasticsearch
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
NEST Breaking Changes | Elasticsearch.Net and NEST
DslPrettyPrintVisitor methods are now virtualedit. This change means that you only need to override the methods that you wish to change the implementation...
Read more >Nest thermostat information menu
The Home or Nest app can give you basic information about your thermostat such as the model, serial number, software version, and other...
Read more >Cooling time limit - Google Nest Community
It would allow you to set say a 4 h h our cool limit. So the unit would run for 4,5,6 (what ever...
Read more >Nest killed my compressor
It seems to be a part of the dual-stage compatibility. Some AC systems are dual-stage, meaning that the compressor can run in 2...
Read more >How To Remove Nest Thermostat From Wall - YouTube
You may need to remove your Nest Thermostat if you are moving, painting or remodeling ... Remove the wires from the Nest Thermostat...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
+1 as well. I think we should break where ES breaks, and try to introduce as little client/refactoring breaking changes as possible from 2.x -> 5.x.
This also simplifies our compatibility matrix and makes it very straight forward as to which versions of ES the client supports. Having a 2.x client and also maintaining bwc in 5.x would add maintenance complexity that I don’t think is worth it considering we have a new shiny 2.x client where we refactored all the ugly bits.
Definitely. We can also go back and mark things in 2.0 as obsolete to give a heads up for 5.x which hopefully results in an easier upgrade path to 5.0.
We should remove these and mark those features and all other deprecated features as deprecated now and release a 2.1.1