This document outlines the versioning and release management strategy for the NF525 functionality within the Maxxton software is a single code base. Clients are forced to upgrade (this is done automatically). Maxxton utilizes a single codebase, meaning all clients are on the same version of the core platform and upgrades are automatically applied. However, the NF525 functionality introduces its own versioning to track changes specific to this area.
Core Maxxton Platform Versioning:
While not the focus of this document, it's important to acknowledge that the Maxxton platform itself has its own versioning scheme. This document concentrates on the NF525 versioning, which is layered on top of the core platform version.
/wiki/spaces/SAP/pages/13042519
...
Next to MXTS versioning, a specific NF525 version number is introduced. With every change in NF525 scope, this version number changes.
A major release is then done and pushed to the current production version (as shared in the previous part). The version for nf525 works in increments.
Any majors release are followed by a release note and in this release note has the full scope of the developments. Following NF525 Versioning:
The NF525 functionality has its own dedicated version number, distinct from the main Maxxton platform version. This allows for granular tracking of changes specifically within the NF525 scope. The NF525 version number will be incremented with every changes specifically within the NF525 scope. The NF525 version number will be incremented with every change that affects the NF525 functionality, regardless of the size or signification of the change.
Release Cycle and Versioning:
Development: All changes related to NF525 are developed and tested.
Release: A new NF525 version is released and deployed to the production environment. This release is tied to the current Maxxton platform version.
Versioning: The NF525 version number is incremented for each release. This increment can be a minor, major, or patch version depending on the nature of the changes. A suggested approach is Semantic Versioning:
Major Version (e.g., 1.0.0 to 2.0.0): Indicates significant changes to the NF525 functionality, potentially including new features or breaking changes.
Minor Version (e.g., 1.0.0 to 1.1.0): Indicates new features or enhancements to existing NF525 functionality.
Patch Version (e.g., 1.0.0 to 1.0.1): Indicates bug fixes, security updates, or other minor changes that do not affect the core functionality of NF525.
Release Notes: Crucially, every NF525 release will be accompanied by detailed release notes. These notes will clearly document all changes included in the release, including:
A summary of the changes.
New features and enhancements.
Bug fixes.
Known issues (if any).
Any changes in behavior or compatibility. This is especially important for changes that may require client-side adjustments.
The corresponding NF525 version number.
BOI TVA DECLA 30-10-30 any changes concerning this later will constitue a release. and Subsequent Changes:
Any changes to the NF525 functionality related to or following the "BOI TVA DECLA 30-10-30" will be treated as a new release and will follow the versioning and release note process described above. This ensures clear tracking of all modifications made to this specific area.
https://maxxton.atlassian.net/wiki/spaces/TP/pages/299991374/FR-Maintenance+records?atl_f=PAGETREE
...