-
Notifications
You must be signed in to change notification settings - Fork 118
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
validator: Reduce severity of release-time-missing on snapshot releases #650
validator: Reduce severity of release-time-missing on snapshot releases #650
Conversation
2f54866
to
07d6bda
Compare
This is not quite what I meant in the bug report... Since there may be a release tomorrow I may just implement that change quickly (but not if the release is deferred to Thursday). |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Logic: snapshot releases are allowed to omit the `date` attribute.
Logic: dates that do exist on snapshot releases should be validated.
…, even for snapshot releases
089f4d8
to
4bda793
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
@ximion my communication on this thread was somewhat verbose, so I'll try to be concise: I'd be glad for any code review on the approach currently coded here (approximately: refactor the issue-emission code to allow a severity to be passed by-argument, and use that functionality to emit a reduced-severity (warning instead of error) notice for |
Sorry to nag: is this likely to be reviewable in the nearish future? I'm very much not a competent C++ developer, so if the changes initially seem rough/unacceptable, I'd probably prefer to close it and await a more robust implementation. |
Closing to reduce my mental overhead of open tasks -- not discouraged about reaching a solution for this, just trying to refocus. My eventual hope with resolution of #570 is that I can re-enable the |
I am very sorry for getting back to this so late and not supervising this PR properly. I had to take some absence from FOSS development for personal reasons. But the actual change was trivial, sorry that you put so much more work into it than necessary! It will ship with the next release :-) |
No problem at all - real life happens, and should take priority. I'm very grateful for 13a94d5 - yep, I got a bit frantic attempting an implementation, but it was fun to try some C again, and I learned some things :) Thanks again! |
Resolves #570.