Release 1.9.0?

[musicinmybrain]

With HDMF 3.12, the submodule for hdmf-common-schema was updated from 5b4cbb31dbafcff51ca70bf218f464b186568151, i.e. the 1.8.0 release tag, to 4d2ddd6387c4e36f21f41964fe8873c083680b15. However:

• there is no new hdmf-common-schema release tag for 4d2ddd6387c4e36f21f41964fe8873c083680b15
• docs/source/hdmf_common_release_notes.rst has not been updated
• common/namespace.yaml and docs/source/conf.py still have 1.8.0 as the embedded version number

It would be very helpful, and less confusing, if the practice of making “proper” hdmf-common-schema releases whenever the schemas used in https://github.com/hdmf-dev/hdmf are updated could be resuscitated.

[oruebel]

Thanks for the issue. This was likely just an oversight during the release.

[rly]

Between the 1.8 release and the current head, the schema itself hasn't changed. Only the configuration and documentation files around it have changed (e.g., CI workflows, copyright dates in Legal.txt). Our process in this case is not well defined.

I think the schema version should not be updated if the surrounding files are updated. Perhaps the repo should have a separate versioning system with separate release notes, e.g., the current head would be tagged 1.8.1, and the schema submodule in HDMF should only point to tagged releases of the schema repo (this second part is generally our policy for the submodule, and in retrospect, we should have done this). The double versioning system may be a little confusing but it would be clearer about what's going on.

Alternatively we could update the schema version. I think that suggests to users that the schema has changed, but it probably doesn't matter much to make "extra" releases.

@oruebel what do you think?

[mavaylon1]

To address @rly question, I don't think the versioning needs to change when there's no schema changes/fixes.

As @rly stated, the update for the newest commit were for dates and an update towards the docs yaml. We don't do version changes for these things. The version number present is correct.

[musicinmybrain]

Thanks for the responses, which are quite reasonable – and I must admit I failed to look closely enough to notice that there were no actual schema changes involved.

[oruebel]

Thanks @rly and @mavaylon1 for the clarification.

I think the schema version should not be updated if the surrounding files are updated.

I agree that basing the version on the schema (the same way we do this in code) is reasonable. Since HDMF is only using the schema, it would be nice (if possible) to have releases of HDMF point to releases of hdmf-common-schema.

[rly]

Since HDMF is only using the schema, it would be nice (if possible) to have releases of HDMF point to releases of hdmf-common-schema.

I agree. For the future, let's try to have HDMF point only to releases of the hdmf-common-schema repo, even if the surrounding files have changed, unless there is a strong reason to point to the head instead. I think it will be less confusing that way. (I told @mavaylon1 otherwise when he asked a few weeks ago, but now I think the above policy would be better.)