This question already has answers here:
how do I install a previous version of meteor JS?
(5 answers)
Closed 4 years ago.
I recently updated my Meteor version from 1.6 to 1.7, which seems to have unexpected bugs. In an attempt to fix them I reinstalled Meteor, which probably deleted old installations, which means I can't go back to 1.6. If I change the version in the .meteor/release file from 1.7 to 1.6.1.2, it says that I need to update the release to 1.7, which means I can't use the old version anymore. Is there any way I can install 1.6 version?
I'm using Windows 10 PC.
Are you tracking your project in version control?
The usual advice here is that you should make sure your app is committed to some VCS before starting the update so you can roll back. This works because Meteor uses the versions in .meteor/release and .meteor/versions to keep track of what to use to run your app.
Rolling back
In the unlikely event that the update leaves your application in a bad state, and you don’t feel like debugging it right away, please make sure your application’s .meteor directory is committed to your version control system (e.g. Git, Mercurial, etc.) before the update, so that it’s easy to revert the changes if you encounter problems.
If you don't have any version control, then my recommendation would be to update .meteor/release as you have tried, and also delete .meteor/versions and allow Meteor to pick versions again that are compatible with 1.6.1.2
Alternatively you could try creating a new project with Meteor 1.6.1.2, add the same package dependencies and copy over the release and versions files for the same set of packages.
$ meteor create 1612 --release=1.6.1.2
$ meteor add <packages from your app>
After you've copied them over, meteor should use version 1.6.1.2 and compatible dependency versions
Related
I setup a new project using Firebase SDK and only get this error when I add FirebaseFirestoreSwift-Beta. I have it in other projects that was built before Mar-8th and have no issues running them but it won't work on any new projects. I have went back and watched videos to make sure I wasn't missing a step when installing. I am using Xcode 12.4
Is this an issue with the Beta or is there something I am missing on my end?
Many apologies, the issue was introduced by me.
It appears that symbol resolution has changed slightly in Swift between Xcode 12.4 and Xcode 13.
I have made a PR that fixes the compilation issue on Xcode 12.4 here:
https://github.com/firebase/firebase-ios-sdk/pull/9438
Until then, if possible, you can update to the latest version of Xcode.
If that is not possible, then if you use a package manager where you can make local edits, you can rename the variable data to something else (like d) to make it compile.
If you can't do that, then a more substantial workaround would be to fork the repository, check out the release tag, create a new branch and fix the error, then pointing your package manager to you own branch including the fix.
Another solution is of course to stay on 8.12 of Firebase until the PR above is merged and released.
is there a way to know when a version of Flyway is going to get deprecated?, actually we were using 6.0.7 the last year and then got deprecated like 6 months ago, now we are using 6.4.1 but I tried to find something on the blog and documentation but there's nothing about some news of when a version is going to be deprecated, only when we run our java spring boot project we know that a version is not usable. And we're aware of this because there's a lot of changes in version 7+ that doesn't work with our project (tested version 7.0.1 and the app crashed) and we need to estimate the cost of the changes.
Any help would be appreciate, thanks.
Flyway releases via Maven OSS. Old versions are kept indefinitely and are outside of Redgate's control. In theory, all older versions which are currently available on Maven will continue to be available for all time.
Newer versions may deprecate features over time, but older versions will always be available.
I have updated mac to 11.6 and xcode to 13.0. Realm could not compile so I updated it with carthage to v10.15.1. Now I get this runtime error just after the app launch:
Library not loaded: #rpath/Realm.framework/Realm
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/RealmSwift.framework/RealmSwift
Reason: tried: '/Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/Realm.framework/Realm' (file does not start with MH_MAGIC[_64], file does not start with MH_MAGIC[_64], fat file, but missing compatible architecture (have 'x86_64,i386', need 'x86_64')), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/Realm.framework/Realm' (no such file), '/usr/lib/swift/Realm.framework/Realm' (no such file), '/Users/username/Library/Developer/CoreSimulator/Devices/33E61712-D8A9-4D7E-A260-5C096BE08A82/data/Containers/Bundle/Application/AC700919-F431-446F-8BEF-FF8D8E5F5BF9/appname.a
I guess the key part here is file does not start with MH_MAGIC[_64], but I could not find anything useful about the error.
I tried embedding the library and turning off the embedding, does not affect anything.
Realm has 3 targets configured to be built with Carthage (Realm, Realm iOS Static and RealmSwift)
XCode 13 deprecated a setting for building targets in a manually set order which leads the first 2 targets to be built in a non deterministic order (the 3rd one is always last as it depends on the 1st one). The order and the frequency of it changing seems to be random (it might depend on the specific XCode version)
When 'Realm' is build before 'Realm iOS Static', the fat framework replaces the one in the xcframework which leads to that error. In the other case, it's the correct one that's built second and overrides the wrong one.
I guess the solution (apart from upgrading Realm) would be to remove the target 'Realm iOS Static' from the project but it's not straightforward to do with Carthage except by forking Realm
The latest version of realm is v10.32.0. xcode 14.1 is also out.
You need to update your toolset.
The latest upgrade realm version 10.32.0 is compatible with XCode 13.1 and above. If you use the legacy build system, migrate it to the latest one and clean the derivable folder before rebuilding the code. Most of the time derivable keeps track of the older version files and makes conflicts once you update the project tools. Hope this will help
Using ASP.NET Core 1.0, is it best practice to check in the project.lock.json file into source control?
Short answer: No, project.lock.file should not be checked into source control - you should configure the version control system to ignore it (i.e. add it to .gitignore if you're using git).
Long answer: The project.lock.json contains a snapshot of project's whole dependency tree - not just packages listed in "dependencies" sections, but also all resolved dependencies of those dependencies, and so on. But it is not like ruby's Gemfile.lock. Unlike Gemfile.lock, project.lock.json doesn't tell dotnet restore which exact versions of packages should be restored - it simply gets overwritten. As such, it should be treated like a cache file and never be checked into source control.
If you check it into version control, then most probably on other machine:
dotnet will think that all packages are restored, but in fact some packages might be missing and the build will fail, without hinting the developer to run dotnet restore
project.lock.json will be overwritten during dotnet restore and in most cases will be different than the version stored in source control. So it will be modified in almost every commit
project.lock.json will cause conflicts during merge
Actually you do want to commit your project.lock.json in git sometimes.
Checking your project json
For the exact reasons that, it shows you the dependencies you have used. Say:
Me as a developer works on an application, i hate every time updating packages so i add a package dependency to nuget package X = 1.*
I restore package i get version 1.2.4
The package maker just made a very stupid mistake, he broke something while just trying to make a fix and release 1.2.5
Person 2 checks out (or even worse release build kicks in).
Person 2 restores and gets version 1.2.5
Person 2 runs your application and find the application is broken.
Person 2 starts debugging and thinks there must be a bug in the software.
At this step 7 Person 2 could have seen in git that his lock file was changed and a newer version of a library has been downloaded, Which has not been tested by any of the other developers!
Downsides
Downsides of checking in this file is you might get allot of merge conflicts on continues updates of packages.
Alternative solution
Use only hard version dependencies (this is quite hard though for nuget). And only manually update to newer version once in a while.
Downsides
This doesn't work if you build a library for other people to use, since you pin them to a certain version of your dependencies.
Dependencies of dependencies still get resolved automatically so if you don't specify them yourself you can't guarantee there version on dotnet restore
Conclusion
If you want to avoid 'Works on my machine' quotes and the hell of constantly manually updating to newer version: Checking the project.lock.json.
And also build a CI/Release build check to test if this file wasn't changed compared to git, before you release (If your software is very critical)!
If this is not a problem and also automatically updating (to a potentially broken package) is not a big problem, you might not want to commit your project.lock.json.
No, it is just a lock file, really you should never check it in when a lock file exists (except if the program who locked it wants to check it into source control, in that case, exclude your lock file!).
My meteor current version is 0.9.4, and I want to try the latest version "1.0-rc11", I've tried meteor update —release 1.0-rc11 and meteor update —release 1.0-rc.11, and I always got this message "Your packages are at their latest compatible versions."
You have packages that are not compatible with the rc.
Meteor 1.0 is out. You may want to try that with meteor update.
Have a look at what the packages you have are and their constraints to find out whether they are compatible with 1.0. If you have older packages it might prevent an update until you sort them out.
You can check the packages you have in your app using meteor list