Transfer from folder-based versioning to branch-based during 7.2

[WorkingRobot]

Apologies for the small kerfuffle during 7.1, but upon the release of 7.2, this repository will change to a branch-based schema versioning layout.

Instead of Schemas/(version id)/(sheet name).yml, we will change to schemas/(sheet name).yml on branch (version id).

Current benefits:

• Comparing between versions will be much easier, especially with GitHub's built-in branch comparisons, for example.
• The latest schema for all sheets will be easily accessible from the main branch.

Current downsides:

• Developers will need to change their codebase to support this change.

I'm not sure if this is 100% the best route to go yet, but discussion is appreciated :)

[ackwell]

overall no opposition to the proposed new structure - code changes for consumption are relatively trivial, and i can see how the proposal improves authoring/usage.

i think the main place i see opportunity for clarification/changes is around the migration path between now and 7.2's cutover, and possibly some tweaks for ease of automation.

to give context on boilmaster (xivapi)'s consumption; a running instance will maintain a local bare clone of this repo, which is fetched on a regular basis. internal requests for schema data are accompanied by the game version the request is associated with, and the most recent known schema prior (or equal) to that game version will be used. consumers of the api are able to control the requested game version and requested schema version - in effect, there is not a clean cut-over time period possible without breaking consumers of the api.

To that end, questions/comments:

• is there a strong need to replace the semantics of the current main branch if the new structure is primarily branch-based? locking main at the point of the cutover and changing default branch to something else would allow for any current consumers (BM included) to fail-soft with old definitions until updated.
• while absolutely more work in the short term, the branch-based and main-with-folders approaches do not conflict - would it be possible to maintain / automate one from the other in this intervening period, to allow active consumers to start moving across ahead of time? for BM specifically, this would help minimise hiccups for api consumers, as i would be able to preemptively notify about re-pinning versions.
• a perhaps more selfish request - some way to disambiguate the gamever branches from other branch usage would be valuable for automation - bare gamever strings requires consuming code to rely on an implicit signal. i'd personally like to see a well-known prefix, i.e. ver/{version string}, but anything that has an explicit well-known disambiguator would work in this regard.

[ackwell]

Any thoughts on 1 / 3?

The first in particular would be quite a relief from an external maint perspective. Something like latest is possibly a more "semantic" representation of a pointer that follows the most recent gamever branch, off the top of my head. (and would be aligned with similar version tagging systems used by other ecosystems)

[ackwell]

ref (3) specifically, this be what i'm trying to avoid:

Regex::new(r"[0-9]{4}\.[0-9]{2}\.[0-9]{2}\.[0-9]{4}\.[0-9]{4}")

while this is not hard in the slightest, it's brittle

[WorkingRobot]

Apologies for not getting back sooner. ver/{game version} seems like a good enough idea. I'm just going to follow the base game version and branch off only when new exd changes come in (you should be able to use a little bit of comparison math to find the applicable branch for any gamever). As for the default branch, it might be a good idea to make a latest branch (that contains only the latest game version's schemas), but I'm not sure if it's a good idea to keep another ver/... branch that stays up to date alongside it.

[ackwell]

Keeping to exclusively ver/{game version} sgtm.

I'd err to say keeping an additional ver/.. that tracks latest-state wouldn't be beneficial - it'd muddy the water of what the ver/ prefix implies.

latest as a tracking branch sgtm, if going forward with such a brach.

---

you should be able to use a little bit of comparison math to find the applicable branch for any gamever

yeah, iw's schema handler just checks for the most recent schema ver that doesn't postdate the game ver:

	.find(|version| version.as_str() <= game_version)

that's been holding up well for a while now, so as long as i can differentiate gamevers, it should be 👌

[wolfcomp]

I support having a latest branch as this would allow me to remove some logic that I already have to make due for with the folder structure in the current state being https://github.com/aers/FFXIVClientStructs/blob/main/ida/luminapie/exdschema.py#L54-L63 and would keep it simpler to just retrieve the latest schema since that is what most people use.

[ackwell]

Separate question; what's the expected workflow for the creation of a new gamever branch?

• orphan branches with discrete commit history
• branch off a shared base structure commit
• branch off the previous gamever branch
• (if distinct from the prior) branch off the default branch

i'm assuming it won't be the first (orphans) given the remnant branches from 7.1, but confirmation would be good.

mainly interested in whether an arbitrary given git commit ref can be assumed to be on one or one-or-more branch histories

[WorkingRobot]

For a new gamever, the plan is the 3rd. I'd like to keep the repository completely as it is and just make a new ver/ branch either for the previous version or the new version (based on what we decide here). I'd also like to make some automation tools that also backport all schema changes to previous versions' branches, assuming that sheet's column hash stays the same.

[ackwell]

cool, sgtm. no particular concerns there - it does mean that most commits will exist on multiple gamevers, but if a consumer wants to find first-gamever-presence, that's still very doable via git.

[WorkingRobot]

Migration is now complete 🎉