[SMT-COMP] [smt-lib] Re: [smt-announce] SMT-LIB Benchmarks on Zenodo

[Clark Barrett]

One DOI per year sounds like a good best practice to me.

-Clark


On Thu, Feb 15, 2024 at 10:25 AM Mathias Preiner <mathias.preiner at gmail.com>
<barrett-forward at cs.stanford.edu> wrote:

> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "SMT-LIB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to smt-lib+unsubscribe at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/smt-lib/26a2a2b8-6a0b-44bd-89bd-e4e6dd4765c0%40gmail.com
> .
>