Versioning?

[Martin-Pitt]

I'm considering using semantic versioning but does it make sense?

The upstream dependency that can break things easily is actually DSP itself. If it gets patched from Steam it can immediately break this library requiring an immediate update.

So it is not like someone could actually linger on a specific major version of this library for a meaningful time unless there are vigilant maintainers pushing patches on something like LTS branches to provide parity to DSP versions — We don't have the resources for this. So right now, semantic versioning makes most sense to indicate 1) updates to handle new DSP versions and 2) changes in the API contract.

I tend to switch between rapid fire and loosey-goosey with my development style — iterating and prototyping excessively in short bursts ideally with little to no friction in my process and feedback loop (ADHD you see). This dev style can be greatly beneficial in more experimental and creative development, especially in the turbulence of reverse engineering that led to this parser but terrible for consistency and reliability expected in a library, sorry.

[Velociraptor115]

That's fine I think semantic versioning could work

But for intuitiveness, I would suggest \<WorkingGameVersion>.\<YYMMDD> or \<WorkingGameVersion>.\<BreakingVersionInParser>.\<CompatibleVersionInParser>

For eg: 21166.240103 or 21166.1.0 or 1.21166.0 It does look weird though, xD

[Martin-Pitt]

Hmmm, yeah I think having game revision followed by the library to indicate breaking or minor versions would do the trick. It's weird but I can also load the package JSON in the library to check against the game version to check if it's old, current or newer.