search

QuestPackageManager / QPM.CLI

QPM command line tool
GNU General Public License v3.0
7 stars 3 forks source link

Feat: QPM Version specification #34

Closed Fernthedev closed 9 months ago

Fernthedev commented 11 months ago

Specify in qpm.json the QPM minimum version required, and doing so enabling feature flags similar to CMake.

This would allow breaking changes seamlessly but at the cost of complexity in use cases and backwards compatibility support.

Fernthedev commented 10 months ago

Decided to use a versioning setup similar to Cargo's editions.

sc2ad commented 10 months ago

This requires that version guarantees are enforced by the schema. In particular, that no breaking schema changes are made to the qpm.json/qpm.shared.json formats unless a version that would otherwise not match is used. Ex, minimum version of 1.0 should not allow 2.0 features if and only if 2.0 is considered a breaking version increment.

Also worth mentioning that the approach of being backwards compatible means that more and more checks are required both for consumers and producers of the tools to verify version validity. Ex, when version 2.0 exists, qpm must support both 1.0 and 2.0 for emits, consumers can decide whether to make a breaking schema requirement change or not (ex, QP only allows 2.0 or better, for example) but the "or better" means that the minimum version must be truly respected and linted against.

Overall is a good approach imo, just wanted to enumerate some thoughts here.

Fernthedev commented 10 months ago

Also worth mentioning that the approach of being backwards compatible means that more and more checks are required both for consumers and producers of the tools to verify version validity. Ex, when version 2.0 exists, qpm must support both 1.0 and 2.0 for emits, consumers can decide whether to make a breaking schema requirement change or not (ex, QP only allows 2.0 or better, for example) but the "or better" means that the minimum version must be truly respected and linted against.

Yep, that's why I largely avoided it until now. I enjoyed the fast paced break stuff but people seem less than happy about it so I suppose I'll do something to reduce that. I think I'll just add new branches for 2.0 logic and completely leave 1.0 logic untouched for example, even if it has bugs or issues. Maybe not. We'll see if we can pull this off