For authors
VERSIONICS accepts five article types. Each of the first four is a peer-reviewed publication of an artifact, not a report about an artifact. Manuscripts must be submitted through the online system (Submit) and prepared with the official template. The journal charges no fees of any kind.
| Article type | Object of review | Body length | Refs |
|---|---|---|---|
| Software Tool Article | A mature, reusable, user-facing research tool or library, from any discipline | 3,000–4,000 words | 10–30 |
| Data Pipeline Article | An executable, portable, composable analysis or processing workflow | 3,000–4,000 words | 10–30 |
| Benchmark Suite Article | A reusable workload, generator, harness or measurement framework | 3,000–4,000 words | 15–40 |
| Version Release Article | A major or substantial minor release of previously published software | 2,000–4,000 words | 5–20 |
| Review Paper (editor invitation only) | The tool, pipeline and benchmark landscape of a task area — capabilities, usability, maintenance state and gaps | More than 10,000 words | 40–120 |
Version Release Articles are accepted only for releases with a demonstrated increment: material new capability, usability, architecture, portability, performance, interoperability, reliability, security or maintainability, evidenced by differential tests or benchmarks against the prior version, with breaking changes, deprecations and a migration path documented. Improvements that make existing capability markedly easier to use qualify on the same footing as new features. Routine patches, dependency bumps and cosmetic changes are not eligible.
Only manuscripts using the official template are considered:
Formatting: clear academic English; Times New Roman 12 pt, 1.5 line spacing, 2.5 cm margins, pages and lines numbered. Every manuscript opens with Title; Authors and affiliations (with ORCID iDs); Highlights (3–5 capability statements of no more than 85 characters each); Abstract (150–250 words, ending with the sentence "This article publishes version X.Y.Z."); Keywords (4–8); followed by the mandatory Artifact Manifest and Usability Summary tables, the body sections fixed for the article type, the declarations, and references. Section names and order must follow the template; conventional research-paper sections (Literature Review, Methodology, Results, Discussion) must not be substituted.
During artifact review, an independent reviewer follows only the public documentation and the Usability Summary from a clean environment, and reports installation time, obstacles and documentation gaps; this account carries the same weight as the scholarly assessment. Verify before submission that a newcomer reaches a working installation and a first meaningful example in well under an hour — minutes, for pip/conda/container installations; that documentation includes a quick-start, a worked example with sample data, and reference documentation for every interface; that error cases produce comprehensible messages, not stack traces; and that a public issue tracker or support contact exists, with limitations and supported platforms honestly stated.
Any manuscript reporting a performance, cost or capability comparison — and every Benchmark Suite Article — must disclose hardware, software versions, parameters and prices in full; declare vendor affiliations and conflicts; report unfavourable as well as favourable results; state statistical uncertainty across repeated runs; and ship the workloads, harness, configurations and raw results needed for independent re-execution. Rankings without a reusable harness and raw results are out of scope.
VERSIONICS uses the numbered (Vancouver) reference style; all references include a DOI where available. Software must be cited with version specificity — both the software article and the exact version used, via the version DOI. Citing a repository home page or a bare software name is insufficient. Provide the same courtesy to your own users through a CITATION.cff stating the preferred citation.
| Stage | Target |
|---|---|
| Initial editorial screening and technical check (scope, template, licence, archive resolvability) | within 10 calendar days |
| Submission to first combined scholarly + artifact decision | within 70 calendar days |
| Submission to final acceptance | within 112 calendar days |
| Acceptance to online publication (copyediting, DOI, badge) | within 14 calendar days |
These timeframes are editorial service targets, not guaranteed processing times; audited performance statistics will be published when a sufficiently complete and verified dataset is available.
Editorial decisions are accept, minor revision, major revision, or reject. Revisions must address both tracks: a point-by-point response to the scholarly reviews and a separate Response to Artifact Review are required with every revised submission. Any change to the software between submission and acceptance — however small — must be released and archived as a new patch or minor version; the manuscript is updated to declare, review and cite that exact version, and the artifact reviewer re-verifies the affected checks.