DEPRECATION NOTICE: Licensed will no longer ship a packaged EXE for future versions >= 4.0.0
jonabc opened this issue · comments
I had to make a choice between locking into the current versions of dependencies or dropping the exe builds, and with a heavy heart I've decided to drop the exe builds. The exe builds are locked to ruby 2.6, which some of licensed's dependencies no longer support. Locking dependencies to their current versions means I'd no longer be able to take any security updates in vulnerable dependencies and would no longer be able to take updates to the license detection gem that this tool is built on, licensee/licensee.
Context
Licensed first starting shipping packaged executables with every release a few years ago to avoid forcing users to install ruby in order to use the tool. Unfortunately due to a series of issues outside my control I'll be removing these executables in an upcoming major version 4.0 release.
The packaged executables are built using a fork of pmq20/ruby-packer that packages a self-expanding squashed file system with ruby 2.6.0 and the ruby code for this project. Unfortunately the ruby-packer project is largely unmaintained now, with the original project only supporting ruby 2.4. Various forks have attempted to build support for newer versions of ruby but it's a non-trivial task. I've looked every so often for updates to, or a fork of, ruby-packer that supports newer versions of ruby but have come up short.
Ruby 2.6 is end-of-life and no longer supported, and I've started hitting issues with dependencies of this project being compatible with ruby 2.7 and above. I've tried looking for a suitable replacement for ruby-packer but I haven't seen anything that has the same ease of use and broad support that ruby-packer provided.
What's next
I'm going to start working on Licensed major version 4, with the only significant change planned at this point being the removal of the packaged executables.
I'd like to be able to say that I could change this decision, but I'm not willing to put licensed's users at risk of security vulnerabilities for ease of use. I hope this is an understandable decision 😢
Alternative workflows for non-ruby developers
Most of the recent usage that I'm directly aware of for licensed has moved off of developers' local machines and into CI flows. Installing ruby in a CI worker is much less impactful to non-ruby developers, and running licensed in a CI workflow ensures that changes to a repository's contents are always run through licensed's status checks.
As one option, I've written a GitHub Action that runs an opinionated status -> cache -> status workflows to automatically update repositories as their contents are changed. The action is not much more than JS scripting that calls bash commands, and parses or handles the various inputs and outputs from each command. If it would be helpful, I could look at creating a bash script that performs similar operations for anyone using an alternative CI system.
I haven't been able to spend as much time on licensed over the past year, so I'll largely be looking to the tool's users and community to consider how best to use the tool in non-ruby environments.
I think this should be a pinned issue. :)
I'm going to close this and leave it pinned for the benefit of easy access and 👀