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!
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.
Ours a complex enterprise app and we use one third party library which we would like upgrade.But we do want to maintain two versions atleast for couple of releases till we are good with the newer version and switch which version to use by a configuration property.
We are trying maven shading for the same.
However the problem we are facing is like this. The changes between the two releases are very drastic. For example A is a class in version 1.0 and is now an interface in version 2.0
So let us say for example in the existing client code we say
A a = new A();
This would have to be changed to some other call in the new version.
Are there any ideas on how to make the client code compatible with both the versions?
I don't believe there is a way to write code compatible with both the versions.
Keeping multiple versions of same jar may create maintenance nightmares.
I suggest to create/maintain separate SVN branches for each version of this jar.
You can decide which SVN branch should go into production based on maturity of that branch.
You can simply replace the war from other branch, if any issue during deployment/in production.
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
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).