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.
Related
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.
I have an installer project setup from version, 1.0.0 ,1.0.1 and 1.0.2.Each having different changes I needed for my project.When I install them in order,they upgrade properly and get installed nicely.But I have a need where I need to go back from 1.0.2 to 1.0.1,but the setup project won't let me install it since it already has a newer version installed.And one of the ways I can get around it, is to manually uninstall it and run it.But I don't want the end user to do that and just run whatever setup he wants and it gets install removing previous versions. Can anyone suggest me a workaround for this or how to handle this situation?
I'm updating my version of Qt for development purposes on my mac.
So I downloaded and installed the opens-source .dmg from the Qt website (https://www.qt.io/).
During installation, I specifically checked the box to install version 5.0.2.
But afterwards, when running qmake -v, it still says the version is 4.8.7.
Make version 2.01a
Using Qt version 4.8.7 in /Users/my_dir/anaconda/lib
(Note: it also points to /lib directory in /anaconda, even though I'm setting this up for Rails purposes. Not sure if this has any impact.)
Can anyone advise how I can change the version that is being pointed to?
Below is what worked for me, incase anyone else has this issue.
Check which version of qmake is being used. which qmake.
Remove anaconda from mac $PATH.
Force homebrew to symlink binaries. brew link --force qt55.
Re-check which version of qmake is being used. which qmake.
When you check the version of qmake the second time, it should point to the new version of qmake that you have installed.
Note: You will have to redo this for every terminal session where you want to use the newer version of qmake.
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.
I need to run a set of tests against the same ruby version and same gemset but with different versions of a .so library.
Therefor I need to have two ruby installations (for the same version 1.8.7), each one pointing to a different set of .so files. How can I do that?
Gemset usage is already too late because library binding is done when rvm install installs a ruby version.
Thanks Rishav, I got the answer through twitter from god himself (aka rvm creator), I can download the real version and the version tagged 1_8_7 on the repository.
Its a hack and will work fine with up to 4~5 different configurations (using tag, revision number, revision date and so on)
Problema solved