Remove validation warnings to stdout

[sudo-bmitch]

Based on our discussion on the June 6th call, we decided to remove the warnings from the code and focus on only things that trigger an error. We had not been maintaining the existing warnings. Anything that only prints to stdout/stderr was deleted since it's unlikely anyone is using that. Private functions that only triggered a print to stdout were deleted.

If others want a stricter validation, those on the call felt it would be better for them to perform that themselves rather than adding new code for OCI to maintain.

Fixes #686.

[tianon]

Agreed, code that nobody is maintaining, ~nobody is using, and nobody (I'm aware of) is asking for is code that shouldn't exist, IMO!

[dontlaugh]

@sudo-bmitch any chance of getting tag for this soon? Even an rc.

Otherwise, if you're targeting a release next year, I can probably convince my team to pin to a commit. A tag would be nicer, though.

Thanks for fixing this so fast, btw.

[tianon]

Our tags are for versions/releases of the spec, not the Go code that comes along for the ride, so it's not likely we'd do a release just for this.

When we looked at this, we couldn't find many public consumers of this code; can you share what you're using it for and what value it's providing to you?

[dontlaugh]

so it's not likely we'd do a release just for this.

That's fine.

We use the function as one of our validation passes for image manifests, which is what we deal with most of the time in our implementation. Our API accepts a raw descriptor and this is a very early check to see if it's something we'll want to deal with.

	if err := schema.ValidatorMediaTypeManifest.Validate(reader); err != nil {
		return nil, err // bad request
	}

We do other validation (specific to our use case, like you all recommend) further down the call stack.

We aren't building an OCI-compliant API, but we do want to store compliant objects, so we're attracted to a method that checks json schema + some basic fields, and that's maintained upstream.

[sudo-bmitch]

I like the idea of periodically cutting patch releases, it's good to exercise the process. But that process requires a 2/3 majority of the maintainers which is a relatively heavy lift. So my personal advice would be to pin to a commit if you need something soon.