- Lynette Rayle (Cornell)
- Jim Coble (Duke)
- LaRita Robinson (Notre Dame)
- Collin Brittle (Emory)
- Tom Johnson (DCE)
- Brian McBride (University of Utah)
- steve van tuyl (oregon state university)
- Carolyn Cole (PSU)
- Chris Colvard (Indiana University)
- Julie Allinson (CoSector, University of London)
- Mark Bussey (DCE)
- Andrew Myers (WGBH)
- Bess Sadler (DCE)
- Jason Corum (WGBH)
- Jennifer Lindner (DCE)
- Ayse Durmaz (Duke)
Roll call by timezone per following order - ensure notetaker is present (moderator)
folks outside North and South America
folks who were missed or who dialed in during roll call
- Welcome all newcomers!
- Agenda (moderator)
- Call for new agenda items (moderator)
- Hyrax 2.1 Update (Tom Johnson)
- Which Rubies do/should we support? (Tom Johnson)
- Hyrax says: "We recommend either Ruby 2.5 or the latest 2.4 version."
- We don't specify ruby support in `hyrax.gemspec`, should we?
- We currently check syntax against Ruby 2.1, preventing use of modern syntax.
- WIP: https://github.com/samvera/hyrax/compare/ruby-2.3
- Hyrax 2.1, SemVer, and You. (Tom Johnson steve van tuyl)
- Notetaker and moderator for next time
- After call, this week's notetaker should create the agenda for the next call.
Hyrax 2.1 Update (Tom Johnson)
- Released Hyrax 2.1 rc3 yesterday
- Testing is ongoing, primarily around permissions
- One blocking issue that will require rc4 #3076
- If you can upgrade a 2.1 app to rc3, that would be helpful, especially if you can help with documentation
- Lynnette: adding a page regarding troubleshooting upgrading migration
- Jim upgraded to rc3 was successful
- Announce successes in the Google Groups thread announcing the rc3
Which Rubies do/should we support? (Tom Johnson)
Background: Hyrax says: "We recommend either Ruby 2.5 or the latest 2.4 version." We don't specify ruby support in `hyrax.gemspec`, should we? We currently check syntax against Ruby 2.1, preventing use of modern syntax. WIP: https://github.com/samvera/hyrax/compare/ruby-2.3
-- Proposal to formalize ruby support to communicate expectations to adopters
-- We should support rubies that are not end-of-life
-- Lynnette seconds that proposal to update our ruby support to newer version. maybe we need documentation on updating ruby version (i.e. updating travis, rubocop, gemfile, etc.)
-- Question for the community: What ought to be our policy re: ruby version support?
-- Trey: do we have a good understanding about rails/ ruby support policies?
-- Rails current support for ruby: Rails 5.2 supports ruby 2.2
-- Tom will make a formal proposal on the tech-list for supporting ruby 2.3+, with future versions to drop support for ruby version in end-of-life status; only support ruby versions with security updates or higher
-- Trey supports Tom's proposal
## Hyrax 2.1, SemVer, and You
- exhibit 1: https://groups.google.com/forum/#!topic/samvera-tech/3V-t_7IEpeE
-- Should Hyrax 2.1 be 3.0? The changes in 2.1 seem to warrant a major release, but the community does not desire more than one major release per year.
-- Jen does not want to create more friction around this release; however, it might be the useful to adopt SemVer practices to introduce stability now, rather than later.
-- 2.1 requires a data migration, and certain methods have been renamed. The extent of the changes depend on the complexity of the customizations made on the apps.
-- Will this take me less than a day of work?
-- Takes a day or two to migrate.
-- Concern: this conversation being had among highly well-connected developers. This will be much more difficult for developers at smaller institutions who are less connected to all of the changes in the stack.
-- The community has repeatedly violated SemVer; this is not specific to Hyrax
-- SemVer is clear. If the community commits to it
-- We should be able to release new features in backwards compatible ways
-- The only change that is not backwards incompatible has to do with admin set ids and collection id; most database changes are backwards compatible (everything related to collections-extensions)
-- Optional database migration with a feature-flipper is backwards incompatible
-- Schema change should be backwards incompatible; changing a field name the shape of the data is not backwards compatible
-- To-do: continue this discussion on the thread
-- Proposal: stick to this release as a 2.1
-- What is the harm with 3.0?
-- We had this conversation months ago, but it seems clear that the conversation did not come to a satisfactory conclusion
-- when all of the technical work is done, we should make the call
Agenda for next week:
- SemVer and Hyrax 2.1