Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing tags for 5.7.* #834

Closed
AMDmi3 opened this issue Jul 2, 2019 · 10 comments
Closed

Missing tags for 5.7.* #834

AMDmi3 opened this issue Jul 2, 2019 · 10 comments

Comments

@AMDmi3
Copy link

AMDmi3 commented Jul 2, 2019

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

@geoffmcl
Copy link
Contributor

geoffmcl commented Jul 4, 2019

@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
Copy link
Author

AMDmi3 commented Jul 4, 2019

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
Copy link
Contributor

geoffmcl commented Jul 8, 2019

@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
Copy link

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
Copy link

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
Copy link
Member

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
Copy link

beutlich commented Jul 26, 2021

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
Copy link
Member

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
Copy link

beutlich commented Jul 26, 2021

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants