Split Hyper-Schema into its own repo?

[handrews]

JSON Hyper-Schema is very much on its own path separate from JSON Schema Core and Validation. I've been going through the issues, and it's a bit hard to see the size of the Core/Validation work with all of the hypermedia stuff mixed in.

Since it's now possible to move issues from one repo to another, should we move Hyper-Schema over? It would still be published through the web site repo. I think it would be good to make it really clear that it's separate from the "main" specifications, and should really be thought of more as an extension vocabulary that happens to be published by the same group doing Core and Validation.

Right now, there's not much going on with it. I hope to revisit it after OpenAPI 3.1 has been out for a while, as there have been sporadic ideas about mixing OpenAPI's static description approach with Hyper-Schema's runtime hypermedia approach, but really JSON Scheme Core/Validation 2019-09 and OAS 3.1 need to be implemented and worked with for a while before that will make sense.

Core and Validation are closely related, even though using Core without Validation has some use cases. But Hyper-Schema has always been kind of its own thing on top of those.

Thoughts?

[Relequestual]

Yes yes! Immediate action!

[handrews]

OK, @philsturgeon has taken care of the repo set-up and moving issues over.

I think this is the set of files that would need to move (with git history! there's an easy way to do this I know although I can't remember it offhand):

meta/hyper-schema.json
output/hyper-schema.json
hyper-schema.json
jsonschema-hyperschema.xml
links.json

And these files need changes:

README.md
Makefile

There is a mention of hyper-schema in CONTRIBUTING.md but it's just explaining that validation and hyper-schema have different meta-schemas so that's probably OK? Unsure.

travis.yml, .gitignore, and at least some of the files in the .github directory would need to be copied over, possibly with small tweaks.

Is there anything else that would need to be done to set up the new repo?

DO NOT DO THIS YET 😄

[handrews]

The other thing to consider is how to handle how the web site repo submodules things in. If we pull the history out into the separate repo, that means none of it remains in this repo, right? So we would need to go update all of the submodule entries for all past drafts from draft-04 onward.

Are there any other web site repo concerns?

I don' think there are test suite repo concerns because we never have had a proper test suite for hyper-schema.

[handrews]

@jdesrosiers this is the issue about the hyper-schema split.

• @Relequestual moved things to the archive dir, did some other stuff, and took hyper-schema out of the build in a series of non-PR commits the day of the 2020-12 draft release
• PR importing the history to the new repo: json-schema-org/json-hyperschema-spec#17
• PR deleting the files (but not the history) from this repo: #1326

Since we're not deleting the history from this repo, the submodule references in the web site repo will continue to work fine. If we want to delete the history we'll have to change that, but I don't see any reason to do so. The past development of Hyper-Schema did occur here and I think it's fine to have that history in both repos: this one for the accurate record of the past, and the new one because you can't "git log" across repos.

[jdesrosiers]

Good enough for me. I just ask that you reference this issue in the PRs, then I'm ready to approve.

[handrews]

@jdesrosiers both are now updated!

[awwright]

I don't think it makes sense to split things into their separate repositories just because they're maintained differently... maybe there's other good reasons, but Git was very much designed for giant monolithic projects (like, say, Linux) over modular ones... I just don't see monolithic repos as a problem, personally. HTTP WG even throws all of the non-core specs together into a single repo.

[awwright]

Also sorry to only be commenting on this just now, but only recently has it struck me, I feel like I'm losing track of all of the different repositories and there's many things that seem to serve the same purpose.

[handrews]

@awwright This was decided two years ago and was mostly completed, I'm just tying up loose ends here.

[jdesrosiers]

I know some people like the monorepo pattern. I'm not a fan and my opinion has nothing to do with the capabilities or limitations of git. I just prefer when separate concerns are in separate repos. It's all about preference. Both choices are valid.

[handrews]

This is now complete.