On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote: > > On Fri, Jan 14, 2022 at 8:30 AM sebb <seb...@gmail.com> wrote: > > > > I'm wondering whether we should pin major version numbers of Gems. > > > > Combined with a regular job to look for outdated Gems, > > I think that would have given us advance warning. > > I gather that the gem in question that was updated was psych. We > don't directly reference it in our Gemfile.
It also affected yaml, but we don't seem to reference that either > There are two major strategies for dealing with dependencies: > > * The one we currently deploy aggressively pulls fixes, which has the > benefit of being automatic, and ensures we are up to date > (particularly with security fixes). But does it need to pull in changes to major versions? Could we not pin the major versions but allow minor updates? > * The other is to check in Gemfile.lock files and only run in > production what has been tested locally. This would request > frequently updating Gemfile.lock files for each whimsy application > locally and checking in the results. Is there any way to get advance notification of which gems have updates? And which have security implications? That would be closer to the way that other ecosystems such as Java work. Or at least if we had notification when there has been a change to a major version of a Gem that would alert us to possible incompatibilities. > - Sam Ruby > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote: > > > > > > I was debugging the same thing, and came to the same conclusion. By > > > the way this affects the roster tool as well as the board agenda. > > > > > > - Sam Ruby > > > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb <seb...@gmail.com> wrote: > > > > > > > > Looks like the API for YAML.safe_load has changed. It now requires named > > > > parameters. > > > > ...
