search

LD4P / sinopia

LD4P Sinopia Project repo to hold docs, general issues, schemas, and related spec docs.
https://ld4p.github.io/sinopia/
19 stars 3 forks source link

clarify versioning instructions for sinopia applications #316

Closed jmartin-sul closed 3 years ago

jmartin-sul commented 3 years ago

Currently, the release checklist for the Sinopia applications specifies bumping the version in package.json (and then regenerating package-lock.json with the new version) for sinopia_editor. It also instructs the person doing the release to tag new versions for all of the Sinopia codebases to be deployed (Sinopia Indexing Pipeline, Sinopia Exporter, and Sinopia API, in addition to the editor), as that's necessary to trigger creation of the Docker images for the latest code.

However, the instructions don't specify a version bump in the package.json for the codebases other than the editor, and as such, the version specified in package.json tends to lag the actual tagged/released/deployed version for those three apps, which is mildly confusing.

We should amend the instructions to prevent this inconsistency.

Updating the version in package.json each time for all of the apps is a bit cumbersome (and Sinopia releases are already rather manual/cumbersome compared to the Rails apps that we just cap deploy). Per @jcoyne, one idea would be to have a very non-specific version in package.json, and have the release tags be more specific (e.g. version is 1 in package.json, version is 1.0.3 for tag). That would prevent the package.json version from disagreeing with the actual release tag, while also preventing the need to update package.json for each app for every deployment. IIRC, @jcoyne also pointed out that version is required in package.json, so we can't just omit the field.

jmartin-sul commented 3 years ago

turns out omitting version doesn't generate complaints from npm i, but using a version of a form other than NUMBER.NUMBER.NUMBER for major/minor/patch, does generate warnings, see

@jermnelson would like to try automatically bumping the version using a github action, as is done in this example, but for now i'll try just omitting the version: https://github.com/cristianpb/muse/actions/runs/121509959/workflow (i've not set up a github action before, and i'm not the most facile with sed, which that example uses, so i'm worried about that approach being a bit of a time sink for me personally)

see also https://github.com/LD4P/sinopia_indexing_pipeline/pull/269/files

jmartin-sul commented 3 years ago

unassigning myself from this, but leaving open in case @jermnelson wants to try the github actions approach.

jmartin-sul commented 3 years ago

deployed the sinopia apps to stage, and the supporting apps seem fine without a version in package.json (or at least sinopia_api does based on a quick smoke test where i searched in the editor and watched the network traffic)