-
Notifications
You must be signed in to change notification settings - Fork 485
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
Release Scorecard - Next release (v4.1.0) #1621
Comments
Are folks working on any new features/changes which we should wait for before creating a release? Also, for some reason the weekly cron jobs haven't been running fine last 2 weeks. I haven't looked into them (might be some GitHub token issue and nothing to do with code itself). But it would be useful to have one successful run and tag that commitSHA as the new release. |
Found the reason why cron job was having issues - #1623. Working on a fix for it, would be good to release after this fix. |
Please provide comments ossf/scorecard-action#97 as well, if you have an opinion. |
Do we need to block Scorecard release for this though? This will rely on scorecard-action release correct? |
you're correct, no need to block scorecard release. I re-phrased my comment :-) |
#1623 is now fixed. I think we are good to release the next minor version. To be safe we can release at 394789cf22887344f084efeffcfe235cc8aa390f which has been tested using the cron job. If folks have any concerns let's discuss before making the release. @naveensrinivasan could you help with creating the new release? |
Yes, getting #1644 in a release would be helpful for Allstar, but we can use hash if you don't want to wait. Thanks |
Merged! |
Scorecard releases are based on commit SHA that has passed cron job. If I am not wrong @azeemshaikh38 is mentioning the SHA https://github.com/ossf/scorecard/tree/394789cf22887344f084efeffcfe235cc8aa390f that has successfully run. So the #1644 might not make it in the release if it is after the above SHA. |
Scorecards is a program first and a library as a far distant second. Allstar is the only consumer that we know of, and we can work around code changes in minor versions. In the future, it might make sense to become more formal about what encompasses the "external" API surface and then follow semver when that changes, but I don't think we are there yet. So far, scorecards major version has reflected major features and milestones in the program's development, so we should consider sticking with that. Thoughts? |
+1. My only consideration for a major version bump was to ease AllStar's move to v4. But given that this is not an issue, my vote is to stick with the minor version bump. |
Fyi, this is what we consider "external APIs", see LTS https://github.com/ossf/scorecard/releases/tag/v3.0.0 |
Looks like we have consensus here? If so, let's close this after releasing the next minor version. We can consider opening a new issue/PR to discuss the updates we need to make in our README about Scorecard versioning. @naveensrinivasan can you help do the release? The latest version of cron run is using commitSHA 33f80c93dc79f860d874857c511c4d26d399609d so we can tag this as our next minor version release. Thanks. |
Awesome, thanks! |
In Scorecard bi-weekly meeting it was brought up about the next version of the scorecard which has some bug fixes.
This is a tracking item to discuss this.
The text was updated successfully, but these errors were encountered: