Let me know if any of the Ruby pieces need updating. I've maintained parallel vocabularies (HTTP and HTTPS), and either can be validated with the linter.

@gkellogg It works without change.
I did try, for completeness to tweak the Rakefile to use the https .nq output but Travis-ci failed - I probably made one too many assumptions - so I put it back.

If you want to take a look at it and see what I should have done, please do.

The release notes say "Download files will continue to support both protocols."

wget --header 'Accept: application/ld+json' -S http://schema.org/docs/jsonldcontext.jsonld

returns (via a 301 redirect) a document with "@vocab": "https://schema.org/" and schema: "https://schema.org/".

The vocabulary definition download files continue to be available containing either http or https based URIs.

Whereas the JSON-LD context file only represents the vocabulary URIs as defined in the coding that defines Schema.org in the repository - which as of version 12.0 has moved to be https based. See the previous comment for a little more detail.

Also note Content negotiation is not supported on the Schema.org site. See comment for detailed description as to why: #2578 (comment)

As per the JSON-LD 1.1 standard machine readable access is indicated via the link value:
link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json"

The Link is after the 301 redirect has occurred.

As shown above: "http://schema.org/docs/jsonldcontext.jsonld" returns the "https" form which is a change (between 14:00 and 18:00 UTC today).

-2021-03-08 23:03:50--  http://schema.org/
Resolving schema.org (schema.org)... 216.58.206.142, 2a00:1450:4009:811::200e
Connecting to schema.org (schema.org)|216.58.206.142|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 301 Moved Permanently
  Location: https://schema.org/
...
  Location: https://schema.org/ [following]
--2021-03-08 23:03:50--  https://schema.org/
Connecting to schema.org (schema.org)|216.58.206.142|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
...
  Link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json"
  Date: Mon, 08 Mar 2021 23:02:38 GMT
...

The site-wide 301 redirect of all http requests to their https equivalents has been a standard feature since its introduction in V7.0 in March 2020.

One thing that did change with the release of V12.0 (approximately 15:35 GMT 2021-03-08) was the contents of the JSON-LD context file. These represent the vocabulary URIs as defined in the coding that defines Schema.org in the repository. This, as per issue #2814, has now moved from being http based to being https based.

It appears v12.0 was to use https://schema.org/ as the namespace for schema.org, switching from http://schema.org/ as indicated in the original v12.0 pre-release, 836cae7. However that change was reverted in 1856ba6. v12.0 release reports http://schema.org/ for the vocabulary URIs.

curl "https://schema.org/docs/jsonldcontext.jsonld"
{
  "@context": {
        "type": "@type",
        "id": "@id",
        "HTML": { "@id": "rdf:HTML" },

        "@vocab": "http://schema.org/",
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "schema": "http://schema.org/",
...

What is the intended vocabulary namespace for schema.org moving forward? https://schema.org/ or http://schema.org/?

The difference does impact downstream processing and recommendations for our community of implementors.