On Sun, 16 Jan 2022 at 16:26, Sam Ruby <ru...@intertwingly.net> wrote: > > On Fri, Jan 14, 2022 at 10:43 AM sebb <seb...@gmail.com> wrote: > > > On Fri, 14 Jan 2022 at 15:12, Sam Ruby <ru...@intertwingly.net> wrote: > > > > > > On Fri, Jan 14, 2022 at 9:52 AM sebb <seb...@gmail.com> wrote: > > > > > > > > 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 > > > > > > Yaml is part of the Ruby core runtime library. It does not provide a > > > safe_load method. But all classes in Ruby are "open". > > > > > > Looking at Gemfile.lock for the board agenda tool, rdoc -- of all > > > things -- pulls in psych. It specifies ">= 4.0.0". > > > > > > Here is the history for psych: https://rubygems.org/gems/psych > > > > > > > > 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? > > > > > > It looks to me like this was released as a minor version. > > > > > > > > * 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. > > > > > > In summary, we are using an API that is not part of the documented > > > interface for YAML, and might be considered "private" to psych. > > > > YAML says it is an alias for Psych, for which safe_load is documented: > > > > > > https://ruby-doc.org/stdlib-2.5.9/libdoc/psych/rdoc/Psych.html#method-c-safe_load > > > > The above version is what we used originally > > > > It looks like it changed in > > > > https://ruby-doc.org/stdlib-2.6.1/libdoc/psych/rdoc/Psych.html#method-c-safe_load > > > > Forgive me in advance for diving into semantics :-) > > From the definition of Semantic Versioning (https://semver.org/), the > difference between 2.5.9 and 2.6.1 is a minor version, and differences in > minor versions are supposed to be backwards compatible. Obviously this > failed here. I've been burned by this enough that I don't place absolute > trust in these distinctions.
Indeed > Ruby and Node.js are examples where recent major versions didn't create > major backwards compatibility issues. > I've seen patch versions of gems take down whimsy applications. > > I'll repeat that it feels weird for us to start pinning versions of gems > that aren't currently in our Gemfiles. It may seem weird, but given the failures we have seen it may be the sensible choice. > I'll close with what an ideal situation would look like: > > * we check in Gemfile.lock files, and have our deployment do 'bundle > install' instead of 'bundle update'. > * we have a comprehensive test suite. Easier said than done. > * we have github actions that will update Gemfile.lock files upon > successful execution of our tests. I don't think bots are allowed to update ASF repos, but they could send an email with details of what to do. At present tests are only run on code changes, otherwise we might have seen the breakage sooner. An interim approach might be to ensure the tests run whenever Gem versions are updated. I don't know if that is possible. > The end result is that we would automatically be kept up to date whenever a > new version of any gem becomes available, as long as that change doesn't > break something. And when there is breakage, we will be notified so that > the problem can be addressed. > > - Sam Ruby > > > > > It changed in a minor version in a way that broke our code. > > > > > > I don't know of any notification mechanism that would help with that > > > combination. > > > > > > - 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. > > > > > > > > > > > > ... > >
