Missing tags for 5.7.*

[AMDmi3]

Repository is missing tags for 5.7.* versions, though version.txt is updated. This is crucial for packaging.

[geoffmcl]

@AMDmi3 thank you for your comment...

Re missing tags... you are sort of right... there has been no tags since the last release, 5.6.0, Nov 25, 2017...

Actually, since github equates tags to releases, per our RELEASE.md docs, there can be no 5.7.*, ie 5.odd tags...

However, there have been some 104 commits to next since then... see commits ... lot of good fixes, unpdates, improvements, etc...

I need some help, or at least encouragement, feedback... to decide on release 5.8.0, or maybe 6.0.0, see #743, #741, etc... what issues should be included, moved on, etc... and do it... it's well overdue... thanks

Use next

Also, since next is kept stable - all development, testing, etc... is done in branches - some distributions use next... probably by tracking version.txt changes, or something... that is much appreciated... thanks...

[AMDmi3]

Actually, since github equates tags to releases

Actually it doesn't. Tags are just tags unless you create a release. And you can mark GitHub release as 'pre-release' too. I do not suggest on pushing for a new stable release, I just note that each version ever mentioned in version.txt should have a corresponding tag.

[geoffmcl]

@AMDmi3 ok, experimentally added a 5.7.28 tag on the next version.txt change...

Hope this improves things for you... to help update distributed tidy... thanks...

[beutlich]

I found it strange that there only are 5.6.0 and 5.7.28 tags available at GitHub tags/releases. Given that 5.6.0 has issues with the (then) newly introduced mute option, I wondered why there is no 5.6.x for it. Thus, I needed to switch to 5.7.28 w/o any alternative and w/o provided binaries.

[beutlich]

I believe the versioning is broken. When the version.txt was incremented from 5.6.0 to 5.7.0 in f0438bd on next branch just immediately after tagging 5.6.0, and later tagging a 5.7.28 from the next branch, while still having an open 5.7 milestone, we notice that 5.7.28 actually should have been a 5.6.28. Having this 5.6.28 perfectly makes sense, since it basically counts the bug-fixes since the 5.6.0 release, while the next minor 5.7 still would be in future. Let me know if you need some help to get it sorted out.

[balthisar]

I'm going to release 5.8 in the near future (within a couple of weeks).

We don't want to officially release odd versions, though, because we make no claims about ABI and API stability between minor versions. In fact, we often break ABI in order to keep our enums sorted, for example.

I agree that we need improved release cadence for stable versions. I'll work on some infrastructure that makes that happen.

In the meantime, I will close this.

[beutlich]

I found it strange that there only are 5.6.0 and 5.7.28 tags available at GitHub tags/releases.

It was not the best idea to remove an existing tag (5.7.28) again as my workflows now fail, e.g., https://github.com/modelica/ModelicaStandardLibrary/pull/3784/checks?check_run_id=3164780076

[balthisar]

Sorry. I was trying to clean up non-releases. Would there be any benefit in adding it back for you? We don't really want to tag non-release versions (anything with an odd minor version number), so I'm sorry it was added in the first place. But if you need it, then we shouldn't break something you already depend upon.

[beutlich]

I updated (and merged) my workflows to no longer depend on the deleted 5.7.28 tag. Thus, it is fine for me. Thanks.

[balthisar]

Sorry about that! I'm glad it's working out, at least.