cocina-models 0.103.0 → 0.103.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 25d2a47837021c38ac5a6f722e53e17fc78c9f07b09efa10d5d2df18a6aa714f
-  data.tar.gz: f52008be424354db1c55160c79ae4511c368b3bcd501a61d86d3ff23f572e57a
+  metadata.gz: 439375f55b48b22cc891dde1fb31519f9b08a42b9128894cf04f643a5644a027
+  data.tar.gz: 7f7a68b92f272e867d6243485d4ed68c1741128c6e93785a1879b811ca0ece63
 SHA512:
-  metadata.gz: bc39f2cd59a93a142503c575469ca20362a17c8a308169140f7f851dcc1099e2b758a8cef019ab52338d8f9ad25a2408c5a5a42d1c024655abc240e15a85f32b
-  data.tar.gz: fc2eb7c64bc4055a957c4ffc6de5a9d3106154eb12171fd214127bf6c8047cbc1e02e3a1ed3b7d33580052b148389174a96e5d7400b60c285dd8c1964c08e909
+  metadata.gz: e23f7d1949ee04c1dba3bea6b64620f0ad816bde8ee02666e8af6b3c3057c86d326f586f696572e8cf0f3ba01c191444cd7501f81a8eede6fcaa45682b69fdfb
+  data.tar.gz: 1b215531fa86e0f049f7c38bd8819c3ae47f849d66b7217da376761e09131f1c23e60b448ae404c66ee6024f6b4f570966a07398719360739182c99e5a2649d1

data/.rubocop.yml

@@ -512,3 +512,12 @@ Style/ItAssignment: # new in 1.70
   Enabled: true
 Style/RedundantFormat: # new in 1.72
   Enabled: true
+
+Style/ComparableBetween: # new in 1.74
+  Enabled: true
+Style/HashFetchChain: # new in 1.75
+  Enabled: true
+Style/ItBlockParameter: # new in 1.75
+  Enabled: true
+RSpec/IncludeExamples: # new in 3.6
+  Enabled: true

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    cocina-models (0.103.0)
+    cocina-models (0.103.1)
       activesupport
       deprecation
       dry-struct (~> 1.0)

data/README.md

@@ -123,23 +123,28 @@ A patch change is a change that (1) does not affect the data model; (2) does not
 
 A patch change can be released as part of regular dependency updates or selectively released for individual applications.
 
-## Releasing major or minor change
-
-NOTE: If dependency updates are about to be released, you have the option of shortening the process and stopping after Step 3. This is because Steps 4 onwards will be taken care of by the regular dependency updates process (basically the updating of cocina-models, dor-services-client and sdr-client as needed in the rest of the associated apps).  You still do need to manually bump some gems and the pinned version of cocina-models in a couple apps and get those PRs approved and merged, as described in Steps 1-3 below.
-
-IMPORTANT: If you do opt to skip steps 4 onward, you should NOT merge the cocina-models bump dor-services-app and sdr-api PRs you created in step 3 until you are ready to finish the dependency updates process.  You can have them reviewed and approved, but if you merge, you will greatly increase the risk of issues if the main branch of DSA or sdr-api are deployed after steps 1-3 are complete but before the rest of the apps are updated to use the new cocina-models via regular dependency updates. The fix for this is to either roll-back DSA and sdr-api to the previous release tag, or proceed forwards with step 4-5.
+## Releasing a major or minor change
 
 Before you release a major or minor change, think about if this release will include new validations.  Even if your change didn't make any changes that would affect validation, there may be other unreleased changes since the previous version of the gem was cut and released.  Best practice is to scan back through the commit history until you get to the last version bump and see if there any significant changes that may affect validation.
 
 If unsure, ask the team or ask for help to just run the validation report anyway (as described above).
 
+### Partial release process
+NOTE: If dependency updates are about to be released, you have the option of shortening the process and stopping after Step 3. This is because Steps 4 onwards will be taken care of by the regular dependency updates process (basically the updating of cocina-models, dor-services-client and sdr-client as needed in the rest of the associated apps).  You still do need to manually bump some gems and the pinned version of cocina-models in the directly coupled apps and get those PRs approved and merged, as described in Steps 1-3 below.
+
+IMPORTANT: If you do opt to skip steps 4 onward, you should NOT merge the dor-services-app and sdr-api PRs you created in step 3 until you are ready to finish the dependency updates process.  You can have them reviewed and approved, but if you merge, you will greatly increase the risk of issues if the main branch of DSA or sdr-api are deployed after steps 1-3 are complete but before the rest of the apps are updated to use the new cocina-models via regular dependency updates. The fix for this is to either roll back DSA and sdr-api to the previous release tag, or proceed forwards with step 4-5.
+
 ### Step 0: Share intent to change the models
 
 Send a note to `#dlss-infra-chg-mgmt` on Slack to let people know what is changing and when.
 
 ### Step 1: Cut the release
 
-The release process is much like any other gem. First bump the version in `lib/cocina/models/version.rb`, then `bundle install` so that `Gemfile.lock` is updated, then commit and push those changes. Then run:
+The release process is much like any other gem. While on main:
+1. Bump the version in `lib/cocina/models/version.rb`
+2. `bundle install` so that `Gemfile.lock` is updated.
+3. Commit those changes. 
+4. Run:
 ```
 bundle exec rake release
 ```
@@ -147,7 +152,11 @@ which pushes the gem to rubygems.org.
 
 ### Step 2: Update client gems coupled to the models
 
-Release new versions of [sdr-client](https://github.com/sul-dlss/sdr-client) and [dor-services-client](https://github.com/sul-dlss/dor-services-client/) pinned to use the new cocina-models version because applications such as [Argo](https://github.com/sul-dlss/argo) and [Dor-Services-App](https://github.com/sul-dlss/dor-services-app) depend on these gems using the same models.
+Release new versions of [sdr-client](https://github.com/sul-dlss/sdr-client) and [dor-services-client](https://github.com/sul-dlss/dor-services-client/):
+1. Pin the new cocina-models version in the clients' `gemspec` files.
+2. Bump the version as described in each client's README release instructions.
+
+Applications such as [Argo](https://github.com/sul-dlss/argo) and [Dor-Services-App](https://github.com/sul-dlss/dor-services-app) depend on these gems using the same models.
 
 ### Step 3: Update services directly coupled to the models
 
@@ -156,27 +165,31 @@ This list of services is known to include:
 * [sul-dlss/sdr-api](https://github.com/sul-dlss/sdr-api)
 * [sul-dlss/dor-services-app](https://github.com/sul-dlss/dor-services-app/)
 
-**NOTE**: You can skip step 3A if there have not been any changes to the `cocina-models` OpenAPI spec since the prior release.
 
 #### Step 3A: Update API specifications
 
-The cocina-models gem is used in applications that have an API specification that accepts Cocina models. Make sure that the `openapi.yml` for these applications include the `openapi.yml` schema changes made in cocina-models.
+**NOTE**: You can skip step 3A if there have not been any changes to the `cocina-models` OpenAPI spec since the prior release.
+
+The cocina-models gem is used in applications that have an API specification that accepts Cocina models. Make sure that the `openapi.yml` for these two applications includes the `openapi.yml` schema changes made in cocina-models.
 
-This can be accomplished by copying and pasting the cocina-models schemas to the openapi.yml of the associated project. By convention, these schemas are listed first in the `openapi.yml` of the associated projects, followed by the application-specific schemas.
+Copy and paste the cocina-models schemas to each project's `openapi.yml`. By convention, these schemas are listed first, followed by the application-specific schemas.
 
 #### Step 3B: Bump gems and create the PRs
 
-If step 3A was needed, use the same PRs to also bump the versions of cocina-models, sdr-client, and dor-services-client in these applications/services. Why? When [dor-services-app](https://github.com/sul-dlss/dor-services-app), for example, is updated to use the new models (via the auto-update script), these clients should be updated at the same time or there is risk of models produced by dor-services-app not being acceptable to the clients.
+If you updated the `openapi.yml` in step 3A, use the same PR for step 3B. Why? When [dor-services-app](https://github.com/sul-dlss/dor-services-app), for example, is updated to use the new models (via the auto-update script), these clients should be updated at the same time or there is risk of models produced by dor-services-app not being acceptable to the clients.
 
-With or without step 3A, perform `bundle update` for cocina-models, sdr-client, and dor-services-client gems in the listed services and then make PRs for those repos. You may first need to update how these gems are pinned in the `Gemfile` in order to bump them.  Note that dor-services-app only needs a bump to cocina-models gem and sdr-api only needs a bump to cocina-models and dor-services-client gems.
+1. Perform `bundle update --conservative cocina-models dor-services-client` in the  services above and make PRs for those repos if they don't already exist. You may first need to update how these gems are pinned in the `Gemfile` in order to bump them.
+2. Note that sdr-client is not currently used in these applications, but if it were, would also need to be bumped to the latest release. 
 
 #### Step 3C: Merge 'em
 
-Get the directly coupled services PRs merged before the deploy in step 5.
+Get the directly coupled services PRs merged before the deploy in step 5. 
+
+See the IMPORTANT note above about the timing of merging these PRs if you are waiting for dependency updates to make the updates to other dependent applications.
 
 ### Step 4: Update other dependent applications
 
-Once the above listed steps have been completed, all applications that use cocina-models should be updated and released at the same time.  "Cocina Level 2" describes this set of updates. The applications that use cocina-models are those in [this list](https://github.com/sul-dlss/access-update-scripts/blob/master/infrastructure/projects.yml) that are NOT marked with `cocina_level2: false`.
+All applications that use cocina-models should be updated and released at the same time.  "Cocina Level 2" describes this set of updates. The applications that use cocina-models are those in [this list](https://github.com/sul-dlss/access-update-scripts/blob/master/infrastructure/projects.yml) that are NOT marked with `cocina_level2: false`.
 
 There are scripts to help with updating other dependent applications:
 
@@ -192,14 +205,13 @@ If for some reason the above method does not work, the sul-dlss/access-update-sc
 ```
 REPOS_PATH=infrastructure GH_ACCESS_TOKEN=abc123 COCINA_LEVEL2= ./merge-all.rb
 ```
-### Step 5: Deploy all affected applications together
+### Step 5: Deploy and test
 
+#### Step 5A: Deploy to Stage or QA
 [sul-dlss/sdr-deploy](https://github.com/sul-dlss/sdr-deploy) has a flag (-c) in the deploy script to limit deploys to cocina dependent applications.  Refer to instructions in the [sdr-deploy/README](https://github.com/sul-dlss/sdr-deploy/blob/main/README.md#only-deploy-repos-related-to-cocina-models-update).
 
 Note that running the integration tests is currently the best way we have to check for unintended effects and/or bugs when rolling out cocina-models changes.
 
-#### Step 5A: Deploy to QA and/or Stage
-
 #### Step 5B: Run infrastructure_integration_tests
 
 It is safest to ensure _all_ the integration tests run cleanly.  However, patch releases of cocina-models may only warrant running individual tests that exercise the changes.

data/lib/cocina/models/mapping/to_mods/title.rb

@@ -185,6 +185,8 @@ module Cocina
             else
               title_parts.each do |title_part|
                 title_type = tag_name_for(title_part)
+                raise "Unknown title type for: #{title_part.to_h}" unless title_type
+
                 title_value = title_value_for(title_part, title_type, title)
                 xml.public_send(title_type, title_value) if title_part.note.blank?
               end

data/lib/cocina/models/version.rb

@@ -2,6 +2,6 @@
 
 module Cocina
   module Models
-    VERSION = '0.103.0'
+    VERSION = '0.103.1'
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: cocina-models
 version: !ruby/object:Gem::Version
-  version: 0.103.0
+  version: 0.103.1
 platform: ruby
 authors:
 - Justin Coyne