Skip to content

Under the Hood: Versioning

Overview

Passwords uses a clear and predictable versioning system so you always know what to expect from each release. This page explains how version numbers work, what each part means, and when each number should be increased.

Passwords follows a simplified form of Semantic Versioning:

MAJOR.MINOR.PATCH   e.g. 1.0.0

Patch Releases (1.0.1, 1.0.2, …)

Used to fix or improve things

A patch release increases the third number and is the most common type of update. It is used exclusively for bug fixes and non‑breaking improvements.

Patch releases include:

  • Crash fixes
  • Incorrect behavior corrections
  • UI glitches
  • Logic errors
  • Memory leaks
  • Packaging or deployment issues
  • Build system fixes
  • Minor internal refactoring that does not change behavior

Patch releases do not include:

  • New features
  • New UI elements
  • New settings
  • Anything that changes how users interact with Passwords

Minor Releases (1.1.0, 1.2.0, …)

Used to add new functionality

A minor release increases the second number and is used when the app gains new capabilities while remaining fully backward‑compatible.

Minor releases include:

New features

  • New menu items
  • New settings
  • New tools or panels
  • New import/export options
  • New UI capabilities
  • New database fields (as long as old databases still work)

Enhancements

  • Performance improvements
  • Workflow improvements
  • Better accessibility
  • More customization options
  • Improved visuals or UX refinements

Minor releases do not include:

  • Breaking changes
  • Anything requiring users to migrate data
  • Removal of existing features

Major Releases (2.0.0, 3.0.0, …)

Used for significant changes which will break older versions

A major release increases the first number and is reserved for changes that fundamentally alter how the app works.

These changes may require:

  • Database migration
  • User action
  • Re‑designing parts of the UI
  • Updating configuration files

Major releases include:

  • New database format or schema changes
  • Removal or replacement of major features
  • Major UI redesign
  • Changes to file paths or configuration structure
  • Anything that makes older versions incompatible

Interpreting the entire Version string (Help.. About)

The About window displays a detailed version string that looks something like this:

1.0.0-debug+2421ea5.main-dirty (2025-12-13 11:15)

1.0.0 The application’s version number in major.minor.patch format.
-debug / -release Indicates the build type. Debug builds are for development and testing; release builds are optimized for everyday use.
+2421ea5 (optional) The Git commit ID the program was built from. This uniquely identifies the exact source code used.
(.main) (optional) The Git branch name used during the build (e.g., main, develop, or a feature branch).
-dirty (optional) Indicates that the build was created while the working directory had uncommitted changes. In other words, the source code was modified locally but not committed at build time. Clean builds omit this suffix.
(2025-12-24 11:15) The date and time the program was compiled, in YYYY-MM-DD HH:MM format.

This detailed version string helps you:

  • Identify exactly which build you are running
  • Report bugs with precise build information
  • Confirm whether you are using a debug or release version
  • Reproduce a specific build later if needed

It’s especially useful when testing new features or diagnosing issues.