Okhttp introduced fastFallback in version 4 and then in version 5, they have introduced that again naming it as HappyEyeballs, can share some share the difference between the two implementations ?
In Okhttp4: https://square.github.io/okhttp/4.x/okhttp/okhttp3/-ok-http-client/fast-fallback/
In Okhttp5: https://square.github.io/okhttp/changelogs/changelog/#version-500-alpha4
It's simpler than that. The URL for the docs is wrong; it should say 5.x and we OkHttp maintainers need to fix that.
Related
I'm having a little trouble reading the rxjs documentation.
As far as I can see, this is the official documentation: https://rxjs-dev.firebaseapp.com/api
In the Observable documenation page under methods it has listed lift() and subscribe(), though later down the page, under examples, there are forEach(), pipe(), and toPromise().
None of those have usage notes - just argument specifiers.
Looking at this page: https://www.learnrxjs.io/operators/utility/topromise.html
We're told:
:warning: toPromise has been deprecated! (RxJS 5.5+)
How I am I meant to be reading this? toPromise was deprecated in 5.5x and continues to be deprecated?
TLDR; I think the documentation is incorrect.
toPromise is not deprecated.
Apparently there was some issue when toPromise was moved to operators and then removed in 5.5 beta.
toPromise was only available in rxjs/operators during a beta of 5.5. It was removed because it doesn't make any sense, it's not an operator, it's a method of subscription that results in a promise.
See GH issue
Also there is no deprecation notice in the sources and none in the migration guide. Rxjs team is pretty reliable about deprecation warnings.
I think the documentation at https://www.learnrxjs.io/operators/utility/topromise.html is either wrong or it's referring to toPromise as operator - which has been removed.
Are there breaking changes in Moment from version 2.1.0 to 2.13.0?
I just inherited a code base that is using the older version and want to know if there will be problems upgrading to 2.13 from 2.1. Unfortunately there are no JavaScript unit tests for our web app.
I can say that in general, moment follows SemVer, so there are no breaking API changes.
However you may find some behavioral changes, as various bugs have been fixed over the years. Some consider it a "breaking change" when they depended on a particular bug being exhibited and later the bug was fixed, or when a function was improved to be more semantically correct.
As an example, the string returned by moment.utc().format() used to include an offset of +00:00, and it now returns Z. This more closely conforms to the ISO8601 and RFC3339 specifications, so the previous implementation was considered a bug, and it has since been resolved. Most people were fine with this change, as either form should be accepted by all modern parsers, but a few folks complained that this broke their code because they were manually parsing the results via string manipulation, and expecting a numeric value for the offset. We don't consider this a breaking change because the API didn't change, and the resulting string was compliant with the spec both before and after the change - it's just more accurate semantically now.
There are a few miscellaneous other changes like this, and they are all referenced in the changelog. If you edit your question to show which features of moment you are using, then I might be able to provide more details.
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
There has to be a name for this. I'm thinking degraded or unused (old isn't descriptive enough). Has anyone come up with something descriptive to call this?
Deprecated (in java) or Obsolete (in c#)
Deprecated
You should use: deprecated
Obsolete for .NET
http://msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx
I ask this question in the hope of collecting all the incompatible changes/bugfixes in Flex 3.*, of which the maintainer of a Flex 2.0.1 application needs to be aware before upgrading. I'm thinking of issues of the following nature:
Bugs in 2.0.1 that had had some workaround, and have been fixed in 3.*, rendering the workaround not only useless but also erroneous.
Bugs introduced in 3.* that worked in 2.0.1, needing new workarounds.
Features that behave slightly differently (events, attributes, etc.).
Incompatible internal changes, that should not effect the progammer, unless they meddled a bit with the internal objects of the framework, like I did. :-)
Anything not fitting in any of these categories.
(I found several such issues, when I last tried this some time ago. Unfortunately I didn't take notes, and I forgot them since then, but I will update this post when I figure them out again. I reported one issue on the Adobe bug tracking site, it was unfortunately deferred.)
It would also be interesting to read about the advantages/drawbacks of such an upgrade. Are there any showstoppers?
here are some links that may help in your endeavors:
http://blogs.adobe.com/flexdoc/2008/02/migrating_from_flex_2_to_flex.html
http://blog.comtaste.com/2007/06/migrate_from_flex_2_to_flex_3.html
http://butterfliesandbugs.wordpress.com/category/flex-migration/
http://butterfliesandbugs.wordpress.com/2008/03/04/understanding-flex-3-migration-issues-part-i/
http://butterfliesandbugs.wordpress.com/2008/03/06/understanding-flex-3-migration-issues-part-ii/
http://butterfliesandbugs.wordpress.com/2008/03/16/understanding-flex-3-migration-issues-part-iii/
For the record, most of the migration problems from Flex 2 to 3 are minor, especially when compared to the problems of migrating from Flex 1.x to 2. I upgraded several applications with no problems at all. That being said, the above links should help note most of the problems you might run into.