can the schemas folder be re-instated?

[kusala9]

It's useful for browsing and resolving questions. Just having the zip files means they have to be downloaded manually and unpacked.

[rmalyankar]

Bad idea. Maintaining the same information in multiple places is a prescription for chaos.
You can always create a new issue and name the schema and version in the issue title.

[rmalyankar]

It was deleted precisely because of confusion caused by people picking up different versions of schemas.

[kusala9]

isn't this exactly what github is for? the management of both individual files and their releases? The entire point of github is to be able to manage sets of flat files (which schemas are), see changes that have been applied to them line by line, and to release them via the github release mechanism. All our date stamped zip files can be released as snapshots. this isn't managing information in multiple places, it's giving visibility to changes. Branches, cloning and pull requests can be used to manage change which is proposed by others. It's only confusing if we don't use it properly.

[RohdeBSH]

@kusala9 You are absolutely right about that.

Uploading zip files is not a good idea on a versioning platform like github.
Any changes made to the individual files within the zip file cannot be versioned and are therefore untraceable. You can work with zip files in a cloud storage, but not on github.
If something really needs to be viewed together, then please in folders.
However, it would be best to use branches and releases/tags to clearly identify the different versions.

[DavidGrant-NIWC]

Agree with @kusala9 and @RohdeBSH; the configuration management features are not being leveraged to promote collaboration and traceability.

I created a sample repo to demonstrate suggested maintenance: https://github.com/DavidGrant-NIWC/s100-schemas

The sample repo manages the files individually and allows you to see what was changed in each commit: DavidGrant-NIWC/s100-schemas@1292623

Individual releases are available from: https://github.com/DavidGrant-NIWC/s100-schemas/releases (the archives were created automatically from the source files).

Note: my repo doesn't always track the file history very well in cases where a file is moved, or when it's duplicated to a new folder and the old folder is retained. In those cases my repo may show a new file (and a file deletion). In order to properly maintain the file history, follow the guidance here for duplicate files: https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904, and use git mv to rename files when they move into new folders.

I'll leave this repo up for a little while, but will delete it eventually. Recommend that going forward this repo, or the repo designated for schema maintenance, be set up and used in a similar manner.

[RohdeBSH]

Hi @DavidGrant-NIWC,

Great work. This is how it should be done.
One small note.
You could still publish the content in the Word and PDF document as Readme.MD. Then it will be displayed on the start page of the repository.

[kusala9]

agree. this is a great way of maintaining the schemas. Then implementers can see at a glance what changes there are on a line by line basis. Branches which contain proposed modifications can then be tested and, crucially, the github can be pulled into source code builds automatically which makes it much smoother to test the impact of new schemas without tediously setting up an autogenrated code interface first. Github's release mechanism means you can easily maintain archives in exactly the same way as the schema server with added traceability.