I've installed amnah/yii2-user library from packagist via composer into my project. The project's composer.json relevant require section looks like:
"amnah/yii2-user": "~2.0"
To my understanding, this should install the latest version with a major version of "2". When I check the installed package via composer show amnah/yii2-user -v, I see the following version information:
versions : dev-master, 2.1.0-alpha4, 2.1.0-alpha3, 2.1.0-alpha2, 2.1.0alpha,
* 2.0.0-alpha2, 2.0.0-alpha, 1.0.0-beta
So 2.0.0-alpha2 is installed, the 2.1 versions are ignored. Isn't it supposed to work like
Another way of looking at it is that using ~ specifies a minimum
version, but allows the last digit specified to go up.
as the documentation states? I'd need the latest 2.x version installed. What am I missing?
If you need the latest 2.x version installed, you should use ~2.1 if "latest" means that at that time a version 2.1 is the most current version released.
But I wonder why you are getting the alpha version installed. Usually Composer defaults to only install stable versions, no release candidates (rc), beta, alpha nor dev versions. Did you add a setting for minimum-stability and/or preferred-stability?
So if you want alpha versions, you should require ~2.1#alpha.
And a word of caution: The project you are using does require yiisoft/yii2: * and yiisoft/yii2-authclient: * - asterisk meaning that ANY version is sufficient. Yii itself claims that the released 1.1 version is incompatible with the newer 2.0 series (which is not yet released), whatever that means.
Related
I have a project that needs to use Ruby with the exact version of 2.7.5.
I tired using Azure's UseRubyVersion#0 to install it:
- task: UseRubyVersion#0
inputs:
versionSpec: "2.7.5"
But this resulted in an error:
##[warning]Specifying an exact version is not recommended on Microsoft-Hosted agents. Patch versions of Ruby can be replaced by new ones on Hosted agents without notice, which will cause builds to fail unexpectedly. It is recommended to specify only major or major and minor version (Example: `2` or `2.4`)
##[error]Version spec 2.7.5 for architecture %s did not match any version in Agent.ToolsDirectory.
Available versions: /Users/runner/hostedtoolcache
2.7.7,3.0.5,3.1.3
As you can see, Azure only provides the latest patch of minor versions, so installing a specific version like 2.7.5 is not possible.
Is there an alternative way to install a specific version of Ruby in an Azure DevOps Pipeline?
You must at least bump to the latest patch version of 2.7 that is 2.7.7. 2.7.6 and 2.7.7 are bringing important security fixes, that's exactly why Azure does not allow old patch versions. You should take this seriously, this could cost your company to shutdown his activity.
More details:
https://www.ruby-lang.org/en/news/2022/04/12/ruby-2-7-6-released/
https://www.ruby-lang.org/en/news/2022/11/24/ruby-2-7-7-released/
At the time of writing, nativescript version on npm is 4.0.2, but on github, there is a tag for 4.1.0. I would like to install 4.1.0, since some bugs have been fixed there.
tns update 4.1.0 returns Could not update the project! error and npm install -g nativescript#4.1.0 returns No matching version found error.
How can I upgrade?
Update to latest version using
npm install -g nativescript
Can also follow the Instructions
https://www.npmjs.com/package/nativescript
UPDATE
You cannot update to 4.1.0 since there is no version on it.
You can however use the following to upgrade / update to the RC
npm install -g nativescript#4.1.0-2018-05-25-11664
Screenshot for above
If that fails
Try updating npm then do the above
This might be caused by npm-audit-report
Reference
Warning: This can be very much bleeding edge. But let me help you navigate it...
NativeScript has several packages that are intertwined.
The CLI (npm i -g nativescript)
The Core Modules (npm i tns-core-modules --save)
The runtimes android or ios (tns platform add ios)
The newer runtimes may depend on features in the core modules; so you might have to make sure you have an updated core modules if you update your runtimes. This isn't always needed; I frequently test out only one of the three things at a time; but occasionally you need to update everything to make it work.
The simple instructions:
npm i -g nativescript#rc
npm i tns-core-modules#rc --save
tns platform remove android
tns platform add android#rc
tns platform remove ios
tns platform add ios#rc
The informative instructions:
The CLI can be very dependent on which version of the runtimes you plan on using. For example the current 4.x cli can't work with the older 2.x projects anymore. However, it does continue to work with recent 3.x projects. And vise-versa; The 2.x CLI won't build 4.x projects correctly. So you are much safer using the same major version of the CLI as the runtimes you plan on using. (Normally you use the latest release runtimes; but if you have existing projects that haven't been upgraded you might still have 2.x projects)
NativeScript has three version tags depending on what you want.
The standard #LATEST, public version (i.e. npm i -g nativescript#latest ) will give you the current latest release version. Typically a npm i -g nativescript is equivalent to #latest; but in cases of core modules it will use the version in the package.json file. So if you want to install the latest release; it is safer to tack on the #latest to make sure you get the latest release.
The #NEXT version; this is actually a LIE. NEXT = Master; this is NOT the NEXT version of NativeScript. This means you will have everything that has been accepted to master including things that might not actually be rolled out for several more versions (or ever). Master can and typically is buggy, some days more than others. Next versions are generated nightly. But it is very useful for testing if a fix works; DO NOT release an app to clients on #next; you will most likely regret it.
The #RC version; this is actually the release candidate. This version shows up typically a week or so before the final release of the next public version. This is normally a fairly safe version to use; these are manually generated releases for them to start doing in-depth testing before the release version. Please note; that once 4.1 is released the RC is going to point to the 4.1 RC; which is older than latest -- not the final release. So you only want to use #RC when it actually points to a newer version than #latest.
Updating NativeScript CLI:
So now to tell what is the current versions you can do:
npm info nativescript and as of today you would see:
'dist-tags':
{ latest: '4.0.2',
next: '4.2.0-2018-05-30-11723',
rc: '4.1.0-2018-05-30-11720' },
Notice that #latest = 4.02, #next = 4.2.x-DATE and #rc = 4.1.x-DATE.
In this case; doing npm i -g nativescript#next will give you the current Master 4.2.x However, since you are wanting 4.1 and preferably a stable version; since RC has been updated to 4.1 already; then your best bet is to do:
npm i -g nativescript#rc --save and you will get 4.1.0 of the CLI.
Now to update your project;
Updating Core Modules:
You would want to do npm info tns-core-modules again to see the tags for the core modules and you would see something like
'dist-tags':
{ latest: '4.0.1',
next: '4.2.0-2018-05-30-01',
rc: '4.1.0-2018-05-30-06' },
So just like the CLI you would use npm i tns-core-modules#rc; please note no -g as this is a package that is installed as part of your app.
Updating the Android Runtimes
Do npm info tns-android
'dist-tags':
{ latest: '4.0.1',
next: '4.2.0-2018-05-30-01',
rc: '4.1.1-rc-2018-05-28-03' },
For the platforms you need to remove the older version; then install the newer version.
tns platform remove android and then tns platform add android#rc
Updating the iOS Runtimes
Do npm info tns-ios
'dist-tags':
{ latest: '4.0.1',
next: '4.1.0-2018-05-25-01',
rc: '4.1.0-rc-2018-05-26-01' },
And then type
tns platform remove ios and then tns platform add ios#rc
Final notes:
Very frequently you can get away with upgrading just the runtimes or core modules without updating anything else. However, if you have issues building or the app crashes on startup; then you probably need to update everything to be in sync.
You can do npm i -g nativescript#4.1.0-2018-05-30-11720 to install a specific version of it. However, in the many years I've done this I can't think of a reason I have had to do anything beyond the tags of #latest, #next or #rc.
Remember there are THREE separate pieces that you need to be aware of; the CLI (which builds the app; but really has no effect on bugs in the app). The Runtimes (i.e. the JavaScript engine that runs your code), and the Core modules (i.e. the code that makes <Label> become the proper text display on each platform. Depending on which layer your issue is in; that is the piece you want to upgrade.
If you are using NativeScript-Angular, NativeScript-Vue, or the NativeScript-Webpack; there are additional pieces you may have to install to make them compatible with a #rc or #next version.
Is there a legacy mode for Cocoapods that allows a user to use a version of Cocoapods as if it was an older one? Eg use 1.0.0 as if it was 0.39 via a command line argument to avoid downloading legacy versions.
You will need the version to be installed. However, there is nothing wrong with having multiple versions installed. You can also delete them if you no longer need a specific version.
Once installed, run the version you want with this:
pod _0.39.0_ YourCommandHere
Change the version number as needed.
I'm using Android Studio 0.8.9 and I have a following line in my build.gradle:
compile group: 'com.nostra13.universalimageloader', name: 'universal-image-loader', version: '1.9.+'
What will be the actual version of the library used in this case? 1.9.0 or 1.9.3 (latest)?
I'm asking because I recently got a bug report in BugSense with a crash in UniversalImageLoader but the stacktrace is not relevant to the latest version (1.9.3)
The + means that it will use the latest version of the 1.9.X series, which according to Maven Central as of now: http://search.maven.org/#search%7Cga%7C1%7Ccom.nostra13.universalimageloader is 1.9.3.
With the version set up like this, if 1.10.0 were to be released, you wouldn't pick it up -- that + symbol is only a wildcard for the third part of the version number triplet. If you wanted to get the latest version regardless, you could use:
compile 'com.nostra13.universalimageloader:universalimageloader:+'
Note that we don't really recommend that you use the + syntax in version numbers for dependencies. For one, it will make a network request to see if there's a new version, which is a problem for a lot of developers trying to work offline. I believe it only checks once a day, but it can still be a problem. More importantly, it can cause your build to fail in unpredictable ways -- if a new version is released and it causes a compile error or bug, it can be mysterious why your build worked yesterday but started failing today.
In the VS solution, I have as dependencies (in the packages.config file)
a package A, version 2.0.0 which has dependency on package B version >= 5.0.0.0. The latest version of A is 2.1.0 and has the same dependencies as in 2.0.0
a package B, version 10.0.0.0. The latest version is 10.0.5.2
I want to update the package A to 2.1.0 so I tried the command
update-package A
in 'package manager console'. But strangely, Nuget updates also the package B to 10.0.5.2.
Someone told me that by default, Nuget will update to the 'bug fix' version, but I haven't found the link about that.
Does anyone know how to tell Nuget to not update other packages automatically ?
For info, I'm using Nuget 2.5, so according to http://docs.nuget.org/docs/reference/versioning, the dependencies are no longer updated during package installation
Thanks.
As far as I'm aware, this cannot be done, and is the main reason we created the ProGet Client Tools.
You might be able to get away with specifying the explicit version by surrounding it in brackets (e.g. [10.0.0.0]) in the packages.config file but that still seemed to grab the bug fix version when I tried it - though I haven't tested it on the latest version yet.
For reference, the NuGet dependency version selection algorithm is described in detail here: http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html