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

Update the toolinfo of WitnessMap for version 0.0.2-dev #1124

Merged
merged 1 commit into from
Nov 22, 2024

Conversation

marian-lingsch
Copy link
Contributor

Currently WitnessMap only copied the witness from a validation benchmark file into the target directory. In general, this is insufficient, since the contents of the witness need to be adjusted to match those of the input task.

Version 0.0.2-dev of WitnessMap adds this support and the toolinfo needs to also be able to interact with it.

@PhilippWendler
Copy link
Member

Do you need to be able to execute old WitnessMap versions with BenchExec? If not, you can remove the outdated code.

Copy link
Member

@dbeyer dbeyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug-fix releases should increase the 3rd number, feature additions (like this) should increase the 2nd number of the version number. (-dev releases should not deserve an own Tool-Info Module.)

Backwards compatibility is required, but not for versions from a day ago that are not yet widely in use.

I would say you should rewrite this once 1.0 is released, and then only support that version and remove all other code.

@marian-lingsch
Copy link
Contributor Author

Bug-fix releases should increase the 3rd number, feature additions (like this) should increase the 2nd number of the version number. (-dev releases should not deserve an own Tool-Info Module.)

Backwards compatibility is required, but not for versions from a day ago that are not yet widely in use.

I would say you should rewrite this once 1.0 is release, and then only support that version and remove all other code.

Sounds good, I will do the required changes once the release of version 1.0 is done

@dbeyer dbeyer merged commit 546b197 into main Nov 22, 2024
15 checks passed
@dbeyer dbeyer deleted the witnessmap-update branch November 22, 2024 15:25
@dbeyer
Copy link
Member

dbeyer commented Nov 22, 2024

@PhilippWendler Thanks for your comment also, which I did not see because I took so long to write mine.

@PhilippWendler
Copy link
Member

@dbeyer This should not have been merged. For example, besides introducing unnecessary complexity, there is also the problem that it does not cache the version.

@PhilippWendler
Copy link
Member

The rule for backwards compatibility of tool-info modules is that if a tool-info module was part of a BenchExec release, then future versions of BenchExec should aim at supporting all the tool versions that the older BenchExec supported as well. So right now we have no expectation of backwards compatibility, but as soon as this code gets into a BenchExec release, it should be kept there.

The version number of the tool does not really has an influence on this.

So if you want to get rid of code for supporting old versions, then do so before the next BenchExec release, which is at the latest tomorrow morning.

@dbeyer
Copy link
Member

dbeyer commented Nov 22, 2024

@dbeyer This should not have been merged. For example, besides introducing unnecessary complexity, there is also the problem that it does not cache the version.

We needed it merged for a documented pre-run (i.e., with a main-git-hash of BenchExec),
while in parallel @marian-lingsch is already rewriting this completely.

All this code will be gone in a few hours.

@dbeyer
Copy link
Member

dbeyer commented Nov 22, 2024

The version number of the tool does not really has an influence on this.

Yes, that part of my review was placed here although mentioned for WitnessMap.

@marian-lingsch
Copy link
Contributor Author

@dbeyer This should not have been merged. For example, besides introducing unnecessary complexity, there is also the problem that it does not cache the version.

Sorry about that I though that your comment #1093 (comment) referred to the kind of backwards compatibility I implemented here.

@PhilippWendler
Copy link
Member

Sorry about that I though that your comment #1093 (comment) referred to the kind of backwards compatibility I implemented here.

You are correct about this. But this is only relevant for released versions of BenchExec.

@marian-lingsch
Copy link
Contributor Author

The rule for backwards compatibility of tool-info modules is that if a tool-info module was part of a BenchExec release, then future versions of BenchExec should aim at supporting all the tool versions that the older BenchExec supported as well. So right now we have no expectation of backwards compatibility, but as soon as this code gets into a BenchExec release, it should be kept there.

The version number of the tool does not really has an influence on this.

So if you want to get rid of code for supporting old versions, then do so before the next BenchExec release, which is at the latest tomorrow morning.

Sorry about that, should be fixed by #1125

@marian-lingsch
Copy link
Contributor Author

Sorry about that I though that your comment #1093 (comment) referred to the kind of backwards compatibility I implemented here.

You are correct about this. But this is only relevant for released versions of BenchExec.

Thanks for the explanation!

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

Successfully merging this pull request may close these issues.

3 participants