Versioning

[MGatner]

I’ve been talking with another dev who is interested in using the repo but would like some way of checking the current version, especially with multiple branches being on separate versions, and patch data lagging sometime.
My first idea which I think would be easy and unobtrusive would be “version.json” in the root that had (at least) the current patch number. The other part of the request was tracking which heroes were changed - my only thought on that was a “lastUpdated” (or something) field on the hero’s JSON file. Open to ideas

[stuaroo]

Would this be a good use of Releases/Tags? I haven't used those much in projects I've worked on but was thinking that might be helpful if anyone wanted to target a previous game version. A version.json file could work as well. We could also add a badge in the readme with the current updated version.

On heroes changed, is it considered a change as we add features or only when data is updated? Just curious if all heroes would be considered "changed" after adding the patch version field, or if it would only be the 4-5 that had talent string updates in the last patch.

[MGatner]

I have an example of versioning using Releases at my fork:
https://github.com/tattersoftware/heroes-talents/releases

Check it out and let me know if I should push this here. I don't have every patch tagged but if we all agree on the format anyone could do some of that work.

[stuaroo]

I like it, do we want to primarily do release versions to match game versions? When new features get added (the recently added tags, for example) is the plan is to point people to the latest commits rather than the most recent version?

[MGatner]

I’m not sure. I think the ideal scenario would have historic content with consistent, current format. Right now if you go back to a previous commit via release you lose things like ability icons. Developers can correct that themselves by just harvesting descriptions, talent levels, etc - but its a drawback to this “Releases” approach.

Moving forward, if we’re going to keep this I think making a release for game patches makes sense (ignoring format updates, bug fixes, etc). But I’m open to other ideas!

[stuaroo]

That's a good point, I hadn't thought about the features you'd lose by using a previous commit like this. And I agree with your ideal scenario but I have no ideas at present how to achieve that.

[MGatner]

Almost a year on this issue, probably time to close it. @stuaroo the tags seem to be working fine. My only other thought on versioning is if we wanted to maintain multiple versions simultaneously, each in their own folder (similar to https://github.com/HeroesToolChest/heroes-data/tree/master/heroesdata).

The issue now is that the commit history is dual-purpose: data structure and content. This means if someone wants to pull hero talents from 6 months ago they will also have the file structure of 6 months ago which isn't compatible with the current structure.

[stuaroo]

That is a very good point, though do you know if heroes-data adds a new feature, like say a new portrait string, are all previous versions updated to pull the portrait string from their relevant version?

We could definitely switch to something similar or the same (because I must admit that feels much cleaner than using commit history too!)

[koliva8245]

It depends on how many versions I have to update. I might do all or some.