Release readiness
StamPOS 1.0.0 is the controlled baseline. User validation is the remaining major gate to general availability.
Version 1.0.0 represents the controlled production baseline; general availability still depends on supportable deployment evidence.
Recommended validation path
Use 1.0.0 as the controlled baseline for structured pilot users. Fix release-blocking defects without adding broad new features, issue patch builds as required, then publish a general-availability installer once validation evidence supports it.
Gate 1: feature and data freeze
Keep the 1.0.0 feature set, database format, supported operating systems, supported printers and approved Linkly payment path stable during validation. Defer non-essential enhancements so testing is performed against a stable target.
Gate 2: internal regression
Repeat installation, upgrade, login, permissions, product management, cash, receipt, event, report, backup, restore, payment, timeout, recovery, refund and settlement tests. Record evidence and known limitations.
Gate 3: controlled user acceptance testing
Use at least one non-developer operator in a realistic environment. Observe setup and normal sales without coaching every step. Capture usability problems, workflow mistakes, confusing wording, hardware issues and support questions—not only crashes.
Gate 4: pilot trading
Run a limited pilot with a defined start and finish, named support contact, independent cash and card reconciliation, backups and a rollback plan. Expand only after the first pilot closes cleanly.
Gate 5: commercial readiness
Finalise pricing, licence terms, support scope, installation responsibility, update policy, refund/cancellation position, privacy handling, invoicing and the process for issuing activation or product keys.
Gate 6: release package
Prepare a signed or verifiable installer, checksum, release notes, known issues, installation guide, supported-hardware list, backup guidance, payment pairing guide and contact path. Archive the source and build inputs used for the released installer.
Minimum 1.0 acceptance criteria
No unresolved defect should risk duplicate payment, incorrect total, silent data loss, unrecoverable database failure or misleading reconciliation. Installation, backup and restore must be repeatable. A normal operator must complete the agreed sales and closeout workflows from the documentation.
After 1.0
Use patch releases for compatible defect and security fixes, minor releases for backward-compatible features and a major release only when compatibility or core behaviour materially changes.