Develop sync

[junghao]

This PR is to align with the latest tag in the origin github.com/fastschema/fastschema by rebasing to master.

Current status:

• fastschema/fastschema has develop as default branch, which is on v0.9.4
• fastschema/fastschema's latest and v0.9.6 tag is on master branch, is 3 commits ahead of develop
• GeoNet/fastschema forked from fastschema/fastschema and using develop as default branch, too.
• We made changes based on HEAD of GeoNet/fastschema, which is based on v0.9.4

Issue:

• when doing go get github.com/fastschema/fastschema you got v0.9.6 => this is expected
• when doing go get github.com/GeoNet/fastschema you got v0.9.6 => this DOESN'T INCLUDE OUR CHANGES. instead, you need to go get GitHub.com/GeoNet/fastschema@develop to get to the HEAD that contains our updates.

That's this PR for: to be able to use go get GitHub.com/GeoNet/fastschema to get our HEAD which contains our updates.

Note:

Cannot use import github.com/GeoNet/fastschema in downstream Go code due to all the functions require fastschema/fastschema.{something} type, not GeoNet/fastschema.{something}. So cannot change the import to GeoNet/fastschema. The GeoNet/fastschema is more like a "GeoNet vendored fastschema/fastschema" instead of a dependency source.

In the end, on the downstream application side, the go.mod looks like:

require github.com/fastschema/fastschema v0.9.6

replace github.com/fastschema/fastschema => github.com/GeoNet/fastschema v0.9.4-0.20260327020951-82f568ae02af

Which looks confusing. So I'm trying to make GeoNet/fastschma v0.9.6-{pesudo version}

[ardrigh]

As per discussion in Slack, I think a different approach is needed to meet the goal of keeping the upstream sync working, alongside deploying using master.

We can do a few things:

• copy the current GeoNet/fastschema:develop branch to a new branch.
• rebase the new branch onto GeoNet/fastschema:master
• revert the changes applied on GeoNet/fastschema:develop
• allow the GeoNet/fastschema:develop branch to remain in sync with upstream fastschema/fastschema:develop
• monitor upstream releases for changes that require a rebase of GeoNet changes.

I can take a look at helping with these if everyone is happy to this approach.

Looking at the fastschema repo, the 3 commits they have on master ahead of develop are literally just the pull request merge commits
fastschema/fastschema@develop...master