I'd like to run alpha/beta versions and current releases alongside older versions.
For instance, I'd like to easily switch between Cocoapods 0.33.1 and 0.34-RC2.
Especially for older apps that we can't invest much time into, that Cocoapods either no longer supports some Podfile formatting, or the Podspec we are referencing uses deprecated directives.
You could use rvm to set up multiple ruby environments. http://rvm.io
Related
I am working on a server migration and upgrade, and I don't code in Ruby at all.
Is there an easy way for me to scan / review the gemfile / installed dependencies to check that latest updated / unpatched dependencies?
The code references to a hundred at least dependencies and I am not sure which are no longer the latest stable version.
You can try bundle with the outdated command and using the --strict parameter to make sure it lists only compatible gems:
bundle outdated --strict
But like I said in my comment above, you usually want to know what you are doing if you plan to upgrade any gem. Any changes to the API or functionality of a gem may break part of or the entire codebase. Make sure you have working backups.
Why should one care about specifying gem version at all if bundler detects Ruby version and manages to get the latest release to match that version. If I'm not a fond of newer version personally, I would disable incrementing with ~> 1.4.4 and in other cases I'd let bundler manage stuff with putting gem name into Gemfile without any argument
The approach you are suggesting - start with the latest version and pin if problems are experienced - works fine for projects that are 1) actively maintained and 2) tolerant of breakage.
Now imagine you have to deliver this project to a customer who then will run it for a year or longer and you won't be there to support it. In this case simply getting the latest release of all dependencies is not necessarily the best strategy. Maybe you would proactively specify major versions of all of your important dependencies instead. Potentially even lock to minor versions which does give more stability at the cost of missing security updates/bug fixes.
The J2Objc Cocoapods page lists the latest version as 0.9.6.1 and this is what pod update fetches. However, the J2Objc git page indicates that the latest version is 2.0.2.
Has the Cocoapod for J2ObjC been deprecated?
The J2ObjC Cocoapod was created and maintained by external developers who use j2objc in their projects, but who are not members of the J2ObjC team. I suggest directly contacting the people on the pod's "Maintained by" links on the podspec page as to its status.
Since it's open-source you can also make the change yourself and send it to them to update the pod. I'm not a Cocoapods user, but it looks like all that's needed is to change the version and source tag in the J2ObjC.podspec.json file, though updating the minimum platforms to iOS 10 and macOS 10.11 would be good to do, too.
Isn't the Gemfile.lock a hack used to perpetuate bad practices in dependency version control?
I.e. Shouldn't developers set the dependency version ranges strictly in the Gemfile?
For example if my Gemfile says that I depend on gem A version 1.0.1 or versions [1.0-2.0), why would I need the .lock?
No, Gemfile.lock makes a lot of sense and is crucial to the concept of automatically picking gem versions. As a developer, you do not need to bother about exact version numbers. You can say "give me whatever version of gem X fits all other versions of all other gems" (by just saying gem 'xyz' without any further information). Or you can tell it to stay within the bugfixing line of an older version of a gem (gem 'xyz', '~> 2.3.0') or whatever.
By adding the exact version in Gemfile.lock you then make sure that the versions stay consistent for all developers (and environments). You make the act of upgrading to a newer version of a gem a conscious (and well-documented) choice instead of a random part of your build/deploy process.
why would I need the .lock?
to install exactly the same versions as all the other guys in the team. Or install in production the same versions that you use in development.
It might happen that a new version of some gem is released while you were collecting sign-offs for your release. You better be sure you install/load exactly the versions that you developed/tested with.
I've recently released version 4 of SBJson. This is a new major version that is not backwards compatible. Since SBJson is widely bundled by other popular libraries I renamed all the classes & enums to make sure it can be used in conjunction with prior versions.
However, I'm not sure how to best handle this situation with CocoaPods. I contributed a 4.0.0 spec to the existing SBJson specs, but I suspect it will be impossible to install version 3.2 and 4.0.0 in the same project. Do I have to clone the 4.0.0 spec into a SBJson4 (notice extra major version number in name) spec as well?
Morning.
If you want users to have both versions installed simultaneously they will probably have to be separate pods.
AFAIK you can't have one pod installed twice in a project. I don't even know how you'd get round the linker errors etc. for that to be possible!