Release roadmap.
Unique Checksum works with ACCRE staff on technical enhancements to the LStore platform, targeting a quarterly release cadence. The objectives below are those targeted for completion during the current term. They are listed without regard to sequence, and the specific content and timing of each quarterly release is determined collaboratively with ACCRE during the term.
Quarterly, determined together.
A quarterly release cadence is the target for the LStore file system throughout the term. What goes into each release is not fixed in advance; it is decided with ACCRE staff as the term proceeds, against the objectives set out below and against what the deployment actually needs.
Institutions evaluating LStore reasonably want to know what is being worked on and how it reaches them. The answer is a regular cadence rather than a set of dated promises: work is grouped into quarterly releases, and the composition of each is settled with ACCRE close enough to the release that it reflects real conditions rather than a projection made a year earlier. That is a deliberate choice. A roadmap with a date against every line reads well and survives contact with reality poorly.
LStore is open source and developed in the open. ACCRE is its home and primary engineering center: the platform was authored there, and the architect and ACCRE SMEs continue to lead its development. The repository is public, and contribution is open to other institutions — Unique Checksum among them. Unique Checksum’s role additionally spans coordination, documentation, release engineering, and the commercialization interface — described further on the Provenance and Services pages.
What is being worked on.
The objectives are grouped below by the part of the platform they address. The grouping is for readability only — it implies no ordering, and no objective is tied to a particular quarterly release.
01Platform correctness & efficiency
Defect resolution and resource-consumption work in the components that carry production load.
| Objective | Scope |
|---|---|
| Holey file encryption-at-rest bugfix | A defect fix in encryption-at-rest handling for sparse files. |
| Depot memory usage | Memory-consumption work in the depot, the component that holds and serves allocations. |
| LFS memory usage | Memory-consumption work in the filesystem layer through which clients reach the platform. |
02Data protection & integration
Encoding performance, and the interfaces through which LStore meets the rest of an institution’s environment.
| Objective | Scope |
|---|---|
| Add ISA-L erasure coding | Additional erasure-coding support alongside the existing implementation. |
| Versity product integration and support | Integration and support work for Versity, the S3-compatible object layer. |
| Additional Hammerspace / LStore development to broaden cross-platform integration | Further work on the orchestration integration described on the Hammerspace page. |
03Deployment & documentation
The work that makes an installation repeatable, and the reference material that makes it operable.
| Objective | Scope |
|---|---|
| Add CLI documentation | Command-line reference documentation for the platform. |
| Ansible deployment for partner appliance production and imaging | Deployment automation for the production and imaging of ecosystem-partner appliances. |
| Ansible deployment with site-management RPMs for Unique Checksum support and customization | Deployment automation and packaged site management supporting Unique Checksum’s customization and support of an installation. |
04Support infrastructure
The escalation path institutions running the platform in production depend on.
| Objective | Scope |
|---|---|
| Automate ticketing submission to the production external commercial support platform | Automated submission into the external commercial support platform through which Unique Checksum receives escalations. |
What it commits to, and what it does not.
A roadmap is useful to an institution only if it is clear about its own status. This one describes work targeted for the term. It is not a delivery schedule.
No objective on this page carries a date. None is assigned to a numbered release. The list is not exhaustive of everything that will appear in a release, and inclusion here is not a warranty that a given objective will be delivered within the term or in any particular form — scope is settled with ACCRE as the work proceeds. Where an objective is completed, it will be reflected in the release it ships in rather than announced against a forecast.
Work described elsewhere on this site as a future enhancement — replicated metadata servers, for instance, discussed on the LServer page — is not part of the objectives for this term unless it appears in the list above.
The general terms under which the material on this site is published are set out on the Legal & privacy page.
Questions about direction.
Institutions evaluating LStore for a production deployment frequently have questions the roadmap does not answer — whether a particular capability is planned, how a requirement might be raised with ACCRE, or how release cadence interacts with a procurement timetable.
Those conversations are welcome. Write to sales@uniquechecksum.com, or see the Engagement Models page for how Unique Checksum works with institutions running the platform.