-
-
Notifications
You must be signed in to change notification settings - Fork 1
Versioning Philosophy
Conky Studio uses a milestone-based versioning approach rather than a strict interpretation of semantic versioning.
Version numbers are based on changes to user workflows, capabilities, and architecture, not simply the number of files changed or the size of an internal refactor.
The goal is to make versions communicate meaningful changes to how users interact with Conky Studio.
Conky Studio follows a four-part milestone versioning scheme:
MAJOR.MINOR.FEATURE.PATCH
Example:
1.0.6.2
│ │ │ └── Patch / maintenance release
│ │ └──── Feature update within the current workflow
│ └────── Workflow-level milestone
└──────── Major architecture generation
Each component represents a different level of user-visible change:
- MAJOR — Fundamental architectural or workflow generation changes.
- MINOR — Significant workflow milestones and major application evolution while maintaining project compatibility.
- FEATURE — New capabilities, node additions, tools, compatibility improvements, and other meaningful enhancements that expand the current workflow.
- PATCH — Bug fixes, stability improvements, performance optimizations, documentation updates, packaging fixes, and other maintenance releases.
This versioning model communicates how Conky Studio evolves from the user's perspective rather than measuring development effort or lines of code.
A major version represents a fundamental shift in Conky Studio.
A major release is reserved for changes that significantly alter:
- The application workflow
- Project compatibility
- Core architecture
- The meaning of a Conky Studio project
- How users create or manage themes
Examples:
- A completely new node architecture
- A new project format that breaks compatibility
- Replacing the current code generation pipeline
- A new rendering system
- Turning the legacy importer into a full Conky-to-native-node compiler
A major version is not based on code size. A large internal rewrite does not automatically require a major version if the user workflow remains the same.
Minor versions represent significant milestones in Conky Studio's evolution while preserving the application's overall identity and maintaining project compatibility.
These releases may introduce substantial improvements across multiple systems but do not fundamentally change what Conky Studio is or how users work with it.
Examples may include:
- A major redesign of the Studio interface
- A significant expansion of project management capabilities
- A new workflow spanning multiple existing systems
- Large architectural improvements that enhance, rather than replace, the existing workflow
- Significant usability improvements across the application
Minor versions are designed to maintain compatibility with existing Conky Studio projects unless a documented migration is required.
Feature versions represent meaningful expansion of Conky Studio while keeping the existing workflow intact.
These releases add capabilities or improve major parts of the application without changing what Conky Studio fundamentally is.
Examples:
- New node categories
- Major new tools
- New import/export capabilities
- New workflow improvements
- Significant compatibility improvements
- Large feature additions
Example:
Added:
- Needle Gauge
- Moon Phase eclipse features
- New source nodes
- New logic nodes
- New visual nodes
- Graph improvements
The workflow remained familiar, but Conky Studio gained significant new capabilities.
Patch releases focus on correctness, stability, and refinement.
They include:
- Bug fixes
- Generator corrections
- UI fixes
- Plugin fixes
- Packaging fixes
- Performance improvements
- Documentation corrections
Example:
Included:
- Glow Pulse trigger detection fix
- Corner Bracket cleanup
- Removal of obsolete plugins
These changes improved reliability without changing the overall workflow.
Not every large engineering change requires a version increase.
Conky Studio distinguishes between:
Large changes that improve the implementation while preserving the user's workflow.
Examples:
- Refactoring code generators
- Improving importer reliability
- Cleaning up architecture
- Replacing internal algorithms
- Removing duplicate systems
These may remain within the current version line if they do not introduce user-visible workflow changes.
Changes that alter what users can do or how they interact with Conky Studio.
Examples:
- A new import model
- A new theme creation workflow
- A new node system
- A new project structure
- A new conversion capability
These may require a Feature, Minor, or Major version increase depending on their scope and impact.
The Legacy Importer overhaul improved:
- Custom Lua handling
- Custom Script handling
- Cache preservation
- Asset management
- Runtime behavior
However, the core workflow remained:
Import Theme
↓
Preserve Existing Behavior
↓
Enhance With Conky Studio
The importer became more reliable, but it did not become a fundamentally different feature.
Therefore, it remained within the existing version line.
A future system that could:
- Understand historical Conky styles
- Analyze old Lua/Cairo themes
- Convert drawings into native Studio nodes
- Automatically rebuild legacy themes as editable graphs
would represent a different workflow.
That would not simply be an importer improvement.
It would be a new generation of the importer and could justify a larger version change.
Before increasing the version number, ask:
"Does this change what Conky Studio is, or does it improve what Conky Studio already does?"
If it improves the existing experience:
- Bug fixes and maintenance → Patch
- New capabilities and tools → Feature
- Significant workflow milestones → Minor
If it changes the identity or architecture of Conky Studio:
- Major version
Conky Studio versions are about user-visible evolution, not development effort.
A one-line fix that changes the entire workflow may deserve a major version.
A thousand-line refactor that makes the existing workflow more reliable may not.
The purpose of versioning is to communicate change clearly, not measure the amount of code written.