stac-model release workflow

[rbavery]

this addresses #13 and I can test and make a release with this workflow once the PR is merged.

The release workflow is to make a release in the Github UI and tag it accordingly with stac-model-v or v in order to publish either the stac-model package or the JSON schema, respectively.

Description

• Adds a job publish-pypi to publish.yaml to publish the stac-model package to PYPI if the tag starts with stac-model-v
• adds a condition to deploy-schema (renamed from deploy) to run if tag starts with v
• updates stac-model version to match what's on PYPI: version 0.1.2

Related Issue

• fixes Invalid stac-model version on PyPI #13

Type of Change

• 📚 Examples, docs, tutorials or dependencies update;
• 🔧 Bug fix (non-breaking change which fixes an issue);
• 🥂 Improvement (non-breaking change which improves an existing feature);
• 🚀 New feature (non-breaking change which adds functionality);
• 💥 Breaking change (fix or feature that would cause existing functionality to change);
• 🔐 Security fix.

Checklist

• I've read the CONTRIBUTING.md guide;
• I've updated the code style using make codestyle;
• I've written tests for all new methods and classes that I created;
• I've written the docstring in Google format for all the methods and classes that I used.

[rbavery]

I'm not sure why the greeting action is failing, but think it is alright to remove and we can always add something like this back in: https://github.com/crim-ca/mlm-extension/actions/runs/8928113824/job/24522932284?pr=14

[fmigneault]

@rbavery
I can't seem to be able to update your branch with the latest main changes.
Please make sure they are applied before bumping/publishing.

[fmigneault]

@rbavery
Something we might need to have some consideration about...
Since the repository will effectively contain tag/release for both the MLM spec and the stac-model utility, the CHANGELOG might get somewhat confusing.

For example, we could have a stac-model-vX.Y.Z release to fix some parsing issue in the pydantic definitions, or the addition of new capabilities/utilities, without actually modifying the spec. Currently, I have defined bumpversion rules to automate CHANGELOG updates along the MLM vX.Y.Z tags, but nothing is done if we only update stac-model. Any thoughts on how we should handle this?

[rbavery]

@rbavery I can't seem to be able to update your branch with the latest main changes. Please make sure they are applied before bumping/publishing.

It's already up to date with main since the latest change on main was two days ago? I'll make sure to check this again once it is ready to merge.

# rave at rave-desktop in ~/work/mlm-extension on git:stac-model-release ● [13:34:27]
→ git merge main
Already up to date.

I'm not familiar with bumpversion, I've been making CHANGELOG updates manually so I don't have a lot of insight on if bumpversion can handle version updates for two entities. Maybe we could have two different CHANGELOG files, one for the spec and one for the package? Or keep the one CHANGELOG but add in stac-model changes to the CHANGELOG manually?

[fmigneault]

Ok weird. Github's UI still displays a 'update branch' button. It's ok if you publish with it merged on your side though.

Bumpversion uses a global current_version setting, so we cannot have the two modules managed by the same configuration. We could however have 2 separate files for each case. I think a single CHANGELOG would be better to help align corresponding versions when we do apply changes to both of them for matching features.

[rbavery]

Ok I'm fine with a single CHANGELOG. We can continue to add the stac_model changes in manually then.

[fmigneault]

Can you give a try in doing this manual update for this case?
This PR is a good example of a stac-model-only update.
I will try with #11 which does both MLM and stac-model.

[rbavery]

closing in favor of #16