The latest folder is a full copy of the newest model version

[ehennestad]

code/generated/resources/latest is a full copy of v5.0: 679 generated files against 678, differing only in the README and Contents files and one ParcellationEntityVersion.m (diff -rq shows five differing files). Every schema rebuild doubles the newest version, and every diff of a rebuild shows each change twice.

openMINDS_Python does exactly the same (openminds/latest and openminds/v5 are byte-identical apart from the version string inside), so both projects inherit the pipeline's decision to treat latest as a version rather than an alias.

The MATLAB reason for a physical copy is that a version is selected by adding its folder to the path, and selectModelVersion("latest") needs a folder to add. That does not require a copy: latest could be resolved to the newest version folder by selectModelVersion and getModelVersion, with a one-line manifest saying which version latest currently is.

Proposal: drop the latest folder from the generated output, resolve "latest" to the newest vN.0 folder at selection time, and record the mapping in schema_manifest.json or a sibling file so tooling and tests can still ask what latest means. The one genuinely different file (ParcellationEntityVersion.m) needs a look first, since a copy that differs from its source is either a pipeline bug or an unversioned change.

🤖 Generated with Claude Code

[ehennestad]

@lzehl @apdavison @Raphael-Gazzotti

Will the version called latest always be the same as the newest vN.0 or is the newest vN.0 pinned, and latest contains all changes after the pin?

What do you think about the proposal above?

[ehennestad]

Correction to the premise of this issue, after diffing the two folders and the upstream schemas.

latest is not a copy of v5.0. Upstream, schemas/latest is the development head after the v5.0 freeze, and it currently differs from schemas/v5.0 in exactly one schema: SANDS/atlas/parcellationEntityVersion.schema.omi.json, where versionInnovation (markdown, multiline) was replaced by versionSpecification (plain text, single line). The upstream release_notes_latest.txt records it as the only change. It came in with the SANDS v6 submodule builds on 2026-06-03, so latest is effectively the first slice of the next model version, and it aligns ParcellationEntityVersion with the other ten *Version types that already use versionSpecification in v5.0.

The one differing generated file here (ParcellationEntityVersion.m) is therefore correct output, not a pipeline artefact. The 297 other schema files are byte-identical between the two upstream folders, which is why the rest of the generated tree is identical too.

The proposal still stands in a weaker form: latest should not be a 679-file copy when it differs from the newest release by one file, but resolving it to v5.0 at selection time would be wrong. Either latest is generated only where it differs and overlays the newest release, or it stays a full folder and the manifest records which release it was derived from and what differs. The second is simpler and matches how the Python library ships it.

Consequence worth noting separately: the openMINDS_instances repository follows the same split. All 9360 parcellationEntityVersions instance files under instances/latest carry versionSpecification, and the same files under instances/v5.0 carry versionInnovation. A v5.0 document holding that property loads into latest with a dropped-property warning, and the reverse.

🤖 Generated with Claude Code