[SMT-COMP] [smt-announce] SMT-LIB Benchmarks on Zenodo

[Mathias Preiner]

On 2/15/24 01:44, BOBOT Francois wrote:
> 
> That's interesting, I though that a community would allow to change
> curators and so would allow to change who can create new versions.
> 
> In https://zenodo.org/help/versioning 
> <https://zenodo.org/help/versioning> , record versioning is expressly
> describe as a way to manage tool versions (of course solver versions!).
> But what you are describing seems to show that it would not be a good
> fit for developer teams that can change.
> 
> Are you sure that maintainers of a record in a community can't be changed?
> 
> Since we plan to use zenodo for smtcomp I would prefer to have clear
> best practice.
> 

The main issue I see here is that once a version is uploaded you cannot 
upload older versions for the same DOI. Since we started uploading the 
2023 release we cannot upload older releases under the same DOI since 
they'd show up as newer versions.

Further, if users cite the benchmarks release and use the "catch-all" 
DOI it's less precise what they actually used since this could be any 
version of SMT-LIB uploaded under this DOI.

For SMT-COMP I'd suggest you upload a dataset per year. I find it 
strange do have one DOI for all SMT-COMP results and then you have to 
sift through the different uploaded versions to actually find the 
results for a specific year.


Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA4AF2BDE778B2463.asc
Type: application/pgp-keys
Size: 4865 bytes
Desc: OpenPGP public key
URL: </pipermail/smt-comp/attachments/20240215/bc2d6704/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: </pipermail/smt-comp/attachments/20240215/bc2d6704/attachment.sig>