enchantment: update freesm version format

[fractal-l]

Role

Suggestion

Update FreesmLauncher version format (e.g. v0.0.1 or something else)

Benefit

increases compatibility when packaging

This suggestion is unique

• I have searched the issue tracker and did not find an issue describing my suggestion, especially not one that has been rejected.

You may use the editor below to elaborate further.

No response

[fractal-l]

GPT suggestions:

1. Semantic Versioning (SemVer):

Example: 1.2.3

Structure: MAJOR.MINOR.PATCH
    MAJOR: Breaking changes or significant updates.
    MINOR: Backward-compatible feature additions.
    PATCH: Bug fixes and minor improvements.
Best for: Libraries, APIs, or projects requiring compatibility awareness.

2. Calendar Versioning (CalVer):

Example: 2025.01, 23.12.15

Structure: YEAR.MONTH[.DAY] or YEAR.WEEK
Best for: Projects with time-based release cycles (e.g., Ubuntu 20.04, Android API levels).

3. Incremental Versioning:

Example: 1, 2, 3

Structure: Simple sequential numbering.
Best for: Small projects or internal tools where detailed versioning isn't required.

4. Decimal Versioning:

Example: 1.5, 2.0

Structure: A simple number with decimals for minor updates.
Best for: Early-stage projects or simple applications with straightforward updates.

5. Named Versioning:

Example: Frost, ArcticFox

Characteristics: Each release gets a unique name rather than numbers.
Best for: Creative projects, games, or non-formal software (e.g., Android versions: Lollipop, Marshmallow).

6. Combined Format:

Example: 2025.1.0, v1.2.2025

Structure: Combines semantic and calendar versioning.
Best for: Complex projects needing time-based tracking and detailed changes.

7. Git Commit Hashes:

Example: 1.2.3-abc123, v2025.01.0-g7e9f0a

Structure: Version number + commit hash from Git.
Best for: Continuous deployment pipelines or development snapshots.

8. Date-Time Stamps:

Example: 20250113-1500, 2025.01.13-15:00

Structure: Release date and time in a sortable format.
Best for: Automated builds, nightly releases, or frequent deployments.

9. Build Numbers:

Example: 1.2.3+45, v2025.1-build.123

Structure: Version number with an incremental build count.
Best for: Systems requiring tracking of individual builds, such as CI/CD environments.

10. Pre-release Tags:

Example: 1.0.0-alpha, 2.3.0-beta.2

Structure: Base version + tag for pre-release stage (alpha, beta, rc).
Best for: Projects in development or testing phases where pre-release tracking is necessary.

11. Epoch Versioning:

Example: 2:1.0.0, 1:2025.01

Structure: EPOCH:VERSION
Best for: Package managers (e.g., Debian) to enforce upgrades when version numbers reset.

12. Hybrid System-Specific Versions:

Example: R2025Q1.001, v10.4-LTS

Structure: Combines release type (LTS, experimental), dates, and version numbers.
Best for: Systems requiring both semantic meaning and time-based relevance.

Recommendations:

Use Semantic Versioning (SemVer) for most software projects needing compatibility tracking.
Opt for Calendar Versioning (CalVer) for predictable, time-driven releases.
Choose Git Commit Hashes or Date-Time Stamps for frequent or automated releases.
Use Build Numbers for CI/CD systems requiring individual build identification.
Consider Named Versions for creative or consumer-focused products.

[notwindstone]

I vote for SemVer. Let's start with version 1.0.0

[fractal-l]

Voting for SemVer/build numbers

[so5iso4ka]

I vote for any format compatible with PKGBUILD, etc.

[s0me1newithhand7s]

mostly idc xO

[fractal-l]

Result of voting:

---

• Naming & Semver: 83%
• Other: 17%