Child pages
  • Samvera Tech Call 2018-05-16

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agenda

  1. Roll call by timezone per following order - ensure notetaker is present (moderator)

    1. folks outside North and South America

    2. Eastern timezone

    3. Central timezone

    4. Mountain timezone

    5. Pacific timezone

    6. folks who were missed or who dialed in during roll call

    7. Welcome all newcomers!
  2. Agenda (moderator)
    1. Call for new agenda items (moderator)
    2. Hyrax 2.1 Update (Tom Johnson)
    3. Which Rubies do/should we support? (Tom Johnson)
      1. Hyrax says: "We recommend either Ruby 2.5 or the latest 2.4 version."
      2. We don't specify ruby support in `hyrax.gemspec`, should we?
      3. We currently check syntax against Ruby 2.1, preventing use of modern syntax.
      4. WIP: https://github.com/samvera/hyrax/compare/ruby-2.3
    4. Hyrax 2.1, SemVer, and You. (Tom Johnson steve van tuyl)
      1. exhibit 1: https://groups.google.com/forum/#!topic/samvera-tech/3V-t_7IEpeE
  3. Notetaker and moderator for next time
    1. Notes: Jennifer Lindner
    2. Moderate: Tom Johnson
  4. After call, this week's notetaker should create the agenda for the next call.

Notes

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