...
- Ontology Interest Group Google Folder https://drive.google.com/drive/u/0/folders/1RGBh4fDZdzpJdwyiUMO8OPWwkcmVYrI0
- VIVO Ontologies on Github: https://github.com/vivo-ontolgyontologies
- OBO Slack https://join.slack.com/t/obo-communitygroup/shared_invite/zt-kpkvg7x3-kz7DeGoYKiY~VGWKO0voQg
...
- Starting with v1.11, because that's the VIVO version we took it from.
- Starting with 1.0 to have a clean start.
- Starting with a completely different semantic versioning number.
- Using release dates like v2023-06-12
- maybe a lot more. Inspire us!
- Philip: My fav --> Using release dates like v2023-06-12
Unless you work out a clear definition schema for what is a major, minor or patch change, then semver.
When using good GH PR titles and PRs don't change unrelated things at the same time, auto changelog when doing a release is enough, imho - Melanie:
- In favor of dates, not easy to decide for definitions for changes
- Clear definition/documentation would be needed for SemVer
- MODS defines major change (new version) as one that is not backwards compatible; changes that do not break existing implementations are considered minor
- Javed: Release dates etc separately as metadate, using SemVer. Approach: Definition of major, minor, patch is how it affects the consumption of the Ontology
- major is when previous version is not compatible (deleting class )
- minor (additive, is legacy SPARQL etc. still working...)
- patch (typo, adding a description, Readme fixes etc. → no semantic impact)
- Brian: Semantic Versioning
- List of releases, better overview about what's current
- would be easier for consumption → if only patch release, no worries about integrating it in a running system
- Versioning should be orthogonal to VIVO versioning, starting with a higher number than being used currently in VIVO versioning
- Tatiana
- tendency to dates, but semver makes it easy to be aware of major changes (and history, persons / reasons behind it)
- Georgy
- Agrees, SemVer is the way to go
- Dragan
- Software developers will agree with SemVer
- There are different perspectives, but taking into account that the VIVO Ontology is being used in VIVO, SemVer would make assessment easier
- SemVer has more information in the name
- VOTE: It will be SemVer
- Which number to choose
- 1.11 because it's the version it comes from
- 1.14 because it's the current VIVO version
- 1.0 would suggest it's already outdated
- 2.0 suggest it's already ahead
- Another approach: Take a number to a higher number to have some buffer and to get people to get used to the idea of separate releases (like 2.0 will be confusing, too)
- If higher number: Where are the lower numbers?
- Documentation is key, independent of the solution
- Latest release in https://lov.linkeddata.es/dataset/lov/vocabs/vivo is 1.6
- Major changes will be collected and a release schedule has to be developed
- Deprecation process has to be used, too
- VOTE:
- We will use Version 1.7.0 as the first release with the status quo in the repo. Then SemVer will apply.
- VOTE accepted
- Maven release
- maven configuration in pom files could be copied from ORCID client API project - https://github.com/vivo-project/orcid-api-client/blob/main/pom.xml
- has to be discussed in detail
...