TAG January 29 2021
Zoom Link: https://zoom.us/j/968367412
- Danny Lamb
- Jared Whiklo
- Rosie Le Faive
- Bryan Brown
- Seth Shaw
- Bethany Seeger
- Release version
- ICC Proposal: Islandora will move from branding with major version numbers (Islandora 7, Islandora 8, etc), and refer to the platform only as Islandora, with semantic versioning used to distinguish the technical milestones, and (potentially) code names used for individual releases.
- how do releases work with an env like Islandora (Drupal/microservices/etc)?
- what is a breaking change requiring a new major release?
- Deployment methods (Bethany)
Thoughts: get drupal modules to true semantic versioning, then we can do releases via git tags (that can be branched later, if need be). Also composer.json files can limit to major version, so minor version can upgrades can happen.
Will this lock you down too much. You can update core first and the later bring the rest of the modules up to speed to work with it.
What is a breaking change? Easier to define when looking at drupal service. Look at what services Islandora core provide and when those things change, those are major. Little changes in how it does things are not important.
For example, if we go down the road of getting rid of Active MQ and Karaf - those could be considered major changes.
Or getting rid of Gemini - a service. You may not notice this change, but something major has.
Islandora will work with out services (if you don't install activemq/karaf). Islandora Default sets up the interactions with services.
Maybe try to move up sprint to tease apart islandora_defaults. Figure out what all the Islandora puzzle pieces do and then how they fit together - which ones are core and which are are expected to be customized by users.
When we release we will not try to have the same number for everything. Things do not have to have the same tags. SemVer for all the drupal modules - keep everything to minor updates. Define what constitutes major updates, since the standard definition doesn't fit here. When we switch to SemVer, Drupal insists that that alone is a major version upgrade - so we'd have to go to 2.
Talked about possible release process: Work on dev; then do a sprint to create a Release candidate; then another sprint for testing/documenting. Then cut a release. The idea of a community tested release is appealing. We could have a VM release candidate to use for testing to make testing easier.
About two install methods: Ansible playbook for production - requires rewriting a bit of it. Ansible is great for development, but once we have folks using docker for dev, it's maybe easier to maybe use the docker stuff (was one thought).
Docker learning curve is a hindrance. Need to learn more about the process for accessing code and accessing things.
There are good manual install notes in the documentation.
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups