https://github.com/dockyard/ember-validations/releases
Currently we have only alpha releases and Since 2.0.0 is not out which might take time as I see there are blocker issues for the release.
I am not sure if I can use 0.0.0 will it have any breaking changes ?
what does 0.0.0 mean here is it Initial stable version which supports ember-cli
I think 0.0.0 is an initial version which just is empty addon.
Since ember-validations does not even have a beta , it cannot be used in production.
Is my understanding correct?
we cannot use 0.0.0 it is not a Ember-cli addon
we should just include js file (self executing js )and use it
ember-validations can be used once 2.0.0 is out currently it has only alpha releases.
Related
I’m having this issue because of the minimum target SDK 31 update for the Play Store
I’ve had the App working well, I changed the TargetSDK in the gradle variables file and I’m getting this error :
Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
Here’s the List of My Plugins :
(npx cap ls)
#capacitor-community/admob#3.2.0
#capacitor/app#1.1.1
#capacitor/haptics#1.1.4
#capacitor/keyboard#1.2.2
#capacitor/push-notifications#1.0.9
#capacitor/splash-screen#1.2.2
#capacitor/status-bar#1.0.8
#codetrix-studio/capacitor-google-auth#3.1.4
[info] Listing plugins for web is not possible.
I’ve read That I need to upgrade some plugins but i don’t know which ones
Can you please help me
To properly support SDK 31/32 you have to upgrade to capacitor 4.
Run npm i #capacitor/cli#latest. And then run npx cap migrate. That will update all capacitor dependencies and plugins to version 4 and make required changes to your native projects.
My project uses .NET Standard Library version 2.1.0. One of the packages that it references is System.Net.WebSockets.Client version 4.0.2.0. This package in its turn has a dependency on System.Security.Cryptography.X509Certificates version 4.1.0. As a result, when I restore before build, this particular version gets downloaded. The issue is version 4.1.0 of System.Security.Cryptography.X509Certificates has a known vulnerability and should get updated to 4.1.2 which has the vulnerability fixed.
I am not sure how to update the version of a package that is being internally referenced from another package which itself is part of the .NET Standard Library.
I am getting flagged in my build for using the non-compliant version of the X509Cerificates package. Any pointers in this regard would be much appreciated.
Thanks.
We have decided to upgrade the Flutter version from 1.22 to 2.0 (migrating to null-safety) in an existing project.
We checkout Flutter v2.0.0 and then run the following command:
dart pub upgrade --null-safety
Flutter nicely resolves all dependency conflicts and sets new versions for packages.
Without changing min environment SDK in pubspec.yaml (staying at ">2.10.0 <3.0.0") we fix all breaking changes in the code.
All errors in vs code disappear so we can compile the code. But, when we do compile we get errors from packages e.g. reorderables, fl_chart, flutter_svg etc. stating some classes are undefined. It seems like packages were compiled with a higher SDK version and they weren't set min SDK version to match the one that they were compiled with.
So the package states it can be compiled with Flutter 2.10.0 but in reality, it fails to compile because in this version of Flutter it is missing some necessary imports.
My question is, is this a problem of packages or a problem in my way of processing with migration?
Is it that packages are lacking properly set min SDK?
My conclusion is that most packages are lacking correctly set SDK version constraints. It seems authors usually compile packages for a certain version and do not check min SDK version required. When running dependency resolver it seems to solve dependencies but in compile time it fails.
What is the difference between the "Upgradable" and "Resolvable" columns in the output of "dart pub outdated"?
Here is an example of a package that can be upgraded to the latest. The Upgradable, Resolvable, and Latest all match:
url_launcher *6.0.11 6.0.12 6.0.12 6.0.12
Here is an example of a package that is already at the highest resolvable version, but can't be upgraded to the absolute latest version. Presumably another dependency is restricting the resolvability to the latest.
rxdart *0.26.0 *0.26.0 *0.26.0 0.27.2
Here is an example of a package that can't be upgraded any higher but has a Resolvable version that is higher. What does this mean? How is this different from the middle case above?
provider *5.0.0 *5.0.0 6.0.1 6.0.1
In addition to the other very useful posted thoughts, I have learned the following helpful details:
Upgradable refers to the highest version that your direct pubspec will permit, which considers the sdk version and the individual package version (whether to upgrade to just minor or also major). When Upgradable is limited, it can likely be your sdk version holding things back. In my case I was using sdk 2.12, but some packages require 2.14 now (Sep 2021).
From the docs:
The latest version allowed by your pubspec.yaml file. This is the version that dart pub upgrade resolves to. The value is - if the value in the Current column is -.
Resolvable refers to the highest version that all of the other packages' dependencies will allow, in addition to your direct pubspec constraints. When the Resolvable is limited, there is usually one package holding everything back, or a major version holding everything back.
From the docs:
The latest version that can be resolved, when combined with all other dependencies. This version corresponds to what dart pub upgrade gives you if all version constraints in pubspec.yaml are unbounded. A value of - means that the package won’t be needed.
Upgradable means an upgradeable version. Generally, minor version updates can be upgraded directly without modification.
Resolvable can use the version, generally a major version update (the 0.x version may have destructive changes, same as major version), may have incompatible interfaces to the previous version, if you update this version, you may need to change some code
Latest The latest version. If it is inconsistent with the Resolvable version, means the SDK version required by the latest version is inconsistent with the current project
The main difference is that Resolvable mains the version you need to reach to resolve outdated issues in your project and Upgradable mains the version you can update of that package.
To resolve it you must find packages you can update and continue updating until you can update the main package.
You can see it in this link about those concepts: Dart pub outdated
Cordova 2.7.0 no longer allows deprecated forms of calls to cordova.exec. For example:
44. 2013-05-09 01:18:29.850 myiOSApp[9764:17903] The old format of this exec call has been removed 1
deprecated since 2.1). Change to:cordova.exec(null, null, "NativeControls", createTabBar",[]);
The latest version of the iOS NativeControls plugin I know of is at Here and it has not been updated to fix this.
Is there a more recent version of NativeControls anywhere else?
Please help me to fix this issues
by
John
This is because of a changes in 2.1 deprecated previous iOS plugin signature to: (void)myMethod:(CDVInvokedUrlCommand*)command;
I've fork the project and made fixes here: https://github.com/noogen/phonegap-plugins/tree/master/iOS/NativeControls