I thought the CocoaPods specs repo listed all officially released versions of a project, but we've found vulnerabilities for versions not in the specs repo, like this which says "Eclipse Mosquitto versions 1.5 to 1.5.2" but the specs repo only has 1.4.8.
I don't know CocoaPods well. Is it common to use CocoaPods not in the specs repo?
I know you can depend on git repo tags so I'm hoping for an answer more like "though you can, people hardly ever do" or "yes, people depend on tagged releases not in the specs repo all the time".
Related
If I run lein install the terminal throws an error:
➜ lein install
If there are a lot of uncached dependencies this might take a while ...
Release versions may not depend upon snapshots.
Freeze snapshots to dated versions or set the LEIN_SNAPSHOTS_IN_RELEASE environment variable to override.
But, if I do what the (obscure) error message suggests and if I prefix
the command with LEIN_SNAPSHOTS_IN_RELEASE=true, it succeeds:
➜ LEIN_SNAPSHOTS_IN_RELEASE=true lein install
If there are a lot of uncached dependencies this might take a while ...
Created /Users/pedro/projects/my-project-name/target/1.3.0-ONE-PROJECT-REPOSITORY-NAME.jar
Wrote /Users/pedro/projects/my-project-name/pom.xml
Installed jar and pom into local repo.
I would like to understand this better.
Why is the prefix needed? Why can't Lein just accept lein install?
What is the reason/context behind this design?
Obs.: on project.clj the project name does not include the word SNAPSHOT. I have:
(defproject my-project-name "1.3.0-ONE-PROJECT-REPOSITORY-NAME" ...
I suspect one of your dependencies are pointing to a SNAPSHOT version?
I guess Leiningen does not allow you to release a "stable" (non-SNAPSHOT) version of anything that depends on something non-stable itself. Imagine your library depending on function xyz in the library [abc "1.0.0-SNAPSHOT"]. But in the snapshot version of abc released tomorrow the function xyz have been refactored, so the function signature is different, or maybe xyz has been removed altogether. Now your stable library doesn't work anymore.
That is why Leining wants it to be a deliberate decision (that takes extra effort) to do such things. But without knowing the exact version of Leiningen and the full dependency tree, I cannot say for sure, nor reproduce the behavior locally.
Also see the Leiningen documentation:
Snapshot Versions
Sometimes versions will end in "-SNAPSHOT". This means that it is not an official release but a development build. Relying on snapshot dependencies is discouraged but is sometimes necessary if you need bug fixes, etc. that have not made their way into a release yet. However, snapshot versions are not guaranteed to stick around, so it's important that non-development releases never depend upon snapshot versions that you don't control. Adding a snapshot dependency to your project will cause Leiningen to actively go seek out the latest version of the dependency daily (whereas normal release versions are cached in the local repository) so if you have a lot of snapshots it will slow things down.
Note that some libraries make their group-id and artifact-id correspond with the namespace they provide inside the jar, but this is just a convention. There is no guarantee they will match up at all, so consult the library's documentation before writing your :require and :import clauses.
I have dependabot integrated into a github repo that I control. I've noticed that dependabot is no longer opening PRs for outdated dependencies, such as rubocop and rubocop-rspec.
I have an open ticket in the dependabot-core repo that describes the issue in more detail, including a log from an update attempt. However, the developers seem to have abandoned the ticket.
Could someone help me identify and resolve the issue with dependabot upgrades?
The issue is that rubocop v1.30.0 bumped the minimum required ruby version to 2.6.
The gemspec in the repo specified the required_ruby_version as >= 2.5.0, which dependabot seems to consider to be incompatible with the rubocop requirement. (I think this is overly strict, as rubocop still supports a a TargetRubyVersion of 2.5.)
Nonetheless, bumping the required_ruby_version to >= 2.6.0 has unblocked the dependabot upgrades.
The logger gem, which has been at version 1.2.8 for 7.5 years, was yanked from rubygems.org today and replaced with version 1.2.7:
https://rubygems.org/gems/logger/versions/1.2.8
This library was not a gem before 1.2.8. The gemspec was added on 2011-05-11:
https://github.com/nahi/logger/commit/af96ca8fbf9ca1a20812a222c27d5c1ccf5d297e
There has never been an official release of a 1.2.7 version, as told by the release history on GitHub:
https://github.com/nahi/logger/releases
There have been no commits to this repo for more than 6 years. If a 1.2.7 version of the library was built as a gem, it was done so from a different source repo. I see no evidence that the nahi repo has been superseded by any other repo.
Does anyone know what happened? At this point, we're going to set the source for this gem to the 1.2.8 release commit on GitHub until there's some official word on this.
EDIT: My question isn't about whether or not the logger gem still needs to be maintained. If that were the case, why publish a new version yesterday? And why go backwards in version numbering? And why is there no record of these changes in the repo? There are big differences in what was marked (but not released) as 1.2.7 back in 2008 (and remember, 1.2.8 was published as a gem for the first time 3 years after that in 2011) and what was published yesterday as 1.2.7. We rely on a gem that requires this gem. Sure, we'll reevaluate whether or not that requirement is still true, but the circumstances around yanking 1.2.8 and replacing it with something that has no (established or announced) record of change is odd.
I just saw this too as I'm doing a clean deploy to my web host. I've raised an issue on the github repo https://github.com/nahi/logger/issues/3
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.
In this question, I mentioned my assumption that rubyforge gems are more official, authoritative, and stable than github forks. One of the people replying to my question said that my assumption might not be accurate.
What have you observed? Do people use github to release early and release often, only putting stable releases on rubyforge, or do people release less often on rubyforge for other reasons (eg rubyforge being more of a hassle)?
Update: This question is a little moot now. Github gems are defunct, and rubyforge gems are going to be moved to rubygems.org.
No difference as far as I can tell.
There is a huge range in quality/stability of gems from both sources. Some are rock solid, others are pre-alpha quality.
It really depends on the gem project itself.
Having said that though, the github model does lend itself to more rapid turn around on issues. It's much easier to fork a project, fix a bug, and submit it back to be included in the original source. So at least on the popular projects, bugs get fixed quicker. So maybe that helps projects mature quicker, but I don't know.
What I noticed is a decreasing quality of GEM released via GitHub compared with the overall quality of GEMS at RubyForge.
IMHO there are at least two major explanation for this behavior:
--
Prior to GitHub the 99% of Rubyist was Subversion-dependent. You can say what you want about Subversion, but it is definitely more easy to use compared with Git and everybody is aware of the trunk/tags/branches layout. Then people started to move to Git. Just a super-limited slice of Subversion users started to use Git with the level of knowledge it should require and, what I noticed, is that people started to forgot about tags.
Once upon a time there were tags. In subversion people were used to release new version based on specific tags so that you can easily detect which version you installed and which was the stable branch.
Nowadays I see tons of libraries always under development in the Git master branch. No tags, no stable branches. In general, when libraries where released via RubyForge there was an higher level of attention to the deployment step.
--
GitHub makes the publishing step no more a hassle. That said, you can easily publish a new GEM simply pushing the gemspec into your repository.
In my opinion this simplicity might can lead to a lower quality. More less-skilled developed started to distribute GEMS because it's as easy as generating a new project with Jeweler (or a similar library) and pushing a git repository. They didn't know much more about release management, backward compatibility, release bumps, release maintenance.
Often I came across an unfinished libraries packaged as a GEM just because the developer forgot to remote the .gemspec file. Each commit caused a new GEM to be build with no apparent coherence and consistence.
I'm absolutely in favor of the "release often" practice but when it makes sense. Git provides an excellent branch support, you don't need to clutter the master branch with tons of unrelated commits and releasing unfinished piece of code that you call libraries.
--
Last but not least, what I probably hate the most is the unlimited duplication of the same GEM. When RubyForge was the unchallenged GEM source, it was quite easy to find and install a new project.
IMHO, GitHub introduced an unnecessary layer of complexity. First, you have GEM both available via rubyforge as mygem and via GitHub as username-mygem. You often need to spend time to figure out which GEM is the most updated and holds the master development.
Furthermore, some popular GEM was no longer updated on RubyForge and many people continues to use them just because RubyGems doesn't notify you about new versions. Easy to understand, if you installed coolgem release 1.2.4 and the same library is now available as superuser-coolgem (release 2.0), RubyGems is not clever enough to tell you a new update is available.
--
Now it's time for a disclaimer.
I'm not saying GitHub users produces crappy GEMS compared with RubyForge. I'm a GitHub user and prior I was a RubyForge user as well. Thousands of GEMS successfully migrated from RubyForge to GitHub without leaving the end-user in the "which one" limbo.
The best example Rails, but I can mention many other GEMs including (but not limited to) Capistrano, Hpricot, RedCloth... All those libraries are now hosted on GitHub and if you carefully look at them you can easily recognize the same level of quality as before.
Last but not least, all those libraries continue to be released via RubyForge as the master source so that you don't need to reconfigure your environment to detect whether to install rails-rails or rails.
Also, the end-user is not affected by development decisions. Take Capistrano for instance. A couple of months ago Jamis announced the end of its commitment to the development. The community took charge of the development and moved the master repository from jamis/capistrano to capistrano/capistrano. What would happen if the GEM was released as jamis-capistrano? All the users would have to switch to the new GEM and the new repository with lot of hassle.
This scenario never arised because RubyForge was and continue to be the main Capistrano delivery hub.
--
In conclusion, I unfortunately notices an overall decrease of GEM quality mainly caused by more people approaching Ruby and RubyGems without the necessary level of knowledge. The same apply to a large number of Rails plugins.
GitHub cannot be labelled as the culprit. When complex things become more easy and more people approach them without an underlying knowledge, it's normal that the quality can decrease because complexity is a natural selection process.
Anyway, there's still an excellent level of quality in the Ruby community. It's amazing to see how Ruby developers are committed to unit testing and other professional programming habits.
Probably less stable and slightly more up to date :)
-r
to answer your question finally: both of the resources you mentioned (rubyforge, github) are now obsolete, since gemcutter is the new and only place for rubygems.
Gemcutter Is The New Official Default RubyGem Host:
http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html