[META] farmOS 4.x

Created on 21 November 2024, about 1 month ago

Problem/Motivation

We are starting to scope out the upgrade path from Drupal 10 to 11 for farmOS. See: 🌱 Update Drupal core to 11.x in farmOS Active

As is tradition, we will be incrementing the farmOS major version from 3.x to 4.x at the same time. This encourages users and developers to be more aware an intentional when they are upgrading their deployments and custom code, in case there are any breaking changes they need to be aware of.

This is also an opportunity for us to consider introducing breaking changes ourselves.

This issue will be for tracking the overall farmOS 4.x upgrade process.

Remaining tasks

User interface changes

TBD

API changes

TBD

Data model changes

TBD

🌱 Plan
Status

Active

Version

3.0

Component

Miscellaneous

Created by

πŸ‡ΊπŸ‡ΈUnited States m.stenta

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @m.stenta
  • πŸ‡ΊπŸ‡ΈUnited States m.stenta
  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    Todo: review #3347412: [META] farmOS 3.x Breaking Changes β†’ for breaking changes that we considered for 3.x but didn't do.

  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    Here is the informal list of ideas for 4.x breaking changes that I've been tracking myself. These are just copied and pasted from a text file, so the next step is to go through and make separate issues/forum topics/PRs for each with more detail.

    • Drupal 11
    • recommend composer / drop support for packaged releases
    • setup wizard
      • install modules (maybe groups of modules for use-cases? recipes?)
      • remove concept of "default modules"
      • do you need API access? generate keys + install farm_api, or give steps to manually set up keys
    • openlayers upgrade (we are on 6, current is 10)
    • add google layers (abandon farm_map_google contrib module) (depends on openlayers 9)
    • add label/tags to ontology_uri field to distinguish multiple values
    • add Purpose taxonomy, referenced by all log types, convert from string on Input logs
    • only revert config for core modules via farm_update
    • deprecate farm_ui_user, replace w/ https://www.drupal.org/project/r4032login β†’ (or recreate internally)
    • Issue #3461548: Upgrade path to plugin attributes
    • drop "official" support for sqlite3?
    • do not autogenerate OAuth2 keys, document how to set them up (see setup wizard idea above)
    • run docker container as www-data (not root)
    • change is_castrated to is_sterile?
    • pcambra: farmos 4 should be a recipe on drupal core + farmos core + farmos contrib
    • immutable quantities / remove entity_reference_revisions dependency
    • inject more common dependencies in quick form base class (eg: entity type manager)
  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    Another breaking change is that Drupal 11 requires PHP 8.3, per: https://www.drupal.org/docs/getting-started/system-requirements/php-requ... β†’

  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    Drupal 11 database version requirements may also be considered a breaking change.

    As for databases, Drupal 11 requires:

    • MariaDB 10.6+
    • MySQL/Percona 8.0+
    • PostgreSQL 16+ w/ pg_trgm
    • SQLite 3.45+

    From https://www.drupal.org/project/farm/issues/3488916#comment-15867568 🌱 Update Drupal core to 11.x in farmOS Active

  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    deprecate farm_ui_user, replace w/ https://www.drupal.org/project/r4032login β†’ (or recreate internally)

    Just checked and r4032login β†’ , doesn't have a D11 release (yet).

    πŸ“Œ Automated Drupal 11 compatibility fixes for r4032login Needs review

    Regardless, I'm giving second thought to replacing farm_ui_user. It is very simple, and does what we need. Adding r4032login instead would be an additional dependency (which we then need to wait for future Drupal version compatible releases of), and it adds a fair bit of config that would always be the same in farmOS. And if we instead replicated what it does (even barebones without config), then it may end up being more code than farm_ui_user anyways. So I'm not sure it's worth it. I'm going to suggest we keep things as-is, but if anyone as a strong opinion otherwise feel free to chime in.

  • πŸ‡ΊπŸ‡ΈUnited States m.stenta
  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    remove concept of "default modules"

    I created an issue for part of this: πŸ“Œ Remove farm_install_modules() installation task Active

    There will probably be some other related issues that spin off of that as well.

Production build 0.71.5 2024