Update changelog and spec version for v1.2-rc.2

[ml-evs]

This PR prepares the v1.2.0 release by updating the changelog and version of the spec.

Closes #429 and closes #433 and closes #412

[ml-evs]

I'll start upgrading this PR to handle the real release rather than rc2 (which I guess we no longer need)

[rartino]

Thanks for working on this!

Seeing a slight need to improve clarity only on the item for the license, I was about to approve this and say, fine to release rc.2 as is, but maybe we can get this into the final changelog. However, then I realized that changelog item also didn't link #497, which I think is more important. So, maybe lets get this in?

Also, while I greatly appreciate the addition of https://specification.optimade.org, I'm a bit worried about that I don't see a strategy regarding versioning there. Should we say that https://specification.optimade.org always shows the latest released (or candidate?) specification, and https://specification.optimade.org/v\<version>/ shows the respective versioned ones?

In fact - with the specification not hosted below https://www.optimade.org/ - it may be helpful if we can manage to insert something like a header (like the warning that is there now), or some other kind of "hoverbox" on the specification page to point people to "https://www.optimade.org" for more info, and links to all the other different versions available; a bit like read-the-docs does it.)

[ml-evs]

However, then I realized that changelog item also didn't link #497, which I think is more important. So, maybe lets get this in?

Yep, fair enough. Sorry for the re-review pings everyone...

Also, while I greatly appreciate the addition of https://specification.optimade.org, I'm a bit worried about that I don't see a strategy regarding versioning there. Should we say that https://specification.optimade.org always shows the latest released (or candidate?) specification, and [https://specification.optimade.org/v](https://specification.optimade.org/v%5C)/ shows the respective versioned ones?

In fact - with the specification not hosted below https://www.optimade.org/ - it may be helpful if we can manage to insert something like a header (like the warning that is there now), or some other kind of "hoverbox" on the specification page to point people to "https://www.optimade.org" for more info, and links to all the other different versions available; a bit like read-the-docs does it.)

This is something I wanted to sort out before the final release. My plan would be to host the latest released version at the canonical https://specification.optimade.org and then have the development version be hosted under https://specification.optimade.org/specification/develop (as it is now). All these changes can be made just by hacking around on the gh-pages branch without need for reviews/PRs here (though perhaps once things are settled we can enforce branch protections on gh-pages too). We can definitely link to the appropriate places from https://www.optimade.org/optimade and add another landing page at https://specification.optimade.org instead of the redirect to the spec.

[ml-evs]

We also need to figure out SSL on that subdomain...

[rartino]

All these changes can be made just by hacking around on the gh-pages branch without need for reviews/PRs here (though perhaps once things are settled we can enforce branch protections on gh-pages too).

Well, I may be reading this overly strict, but thinking about this changelog entry after we've added more releases, that link could be a bit more clear on what precisely the URL links to and/or be updated with version numbers.

We also need to figure out SSL on that subdomain...

Yeah, this actually quite painful, and has required going via netlify due to the certificate setup used by UCLouvain.

Not to undo the fine work with the specification subdomain, but are there good reasons for going with a separate subdomain for this, rather than to create a new 'specification' repo that uses the GitHub pages feature of automatically getting the specifications hosted under https://www.optimade.org/specification ? (Much like, I see that by accident we host the providers page also under https://www.optimade.org/providers ...; maybe we should turn that off.)

It would be nice avoid adding one more subdomain to worry about the SSL certificate renewal of...

[ml-evs]

Well, I may be reading this overly strict, but thinking about this changelog entry after we've added more releases, that link could be a bit more clear on what precisely the URL links to and/or be updated with version numbers.

I think for a release candidate this is fine; let's merge as-is and come back to this discussion. Either way it should be clear upon visiting whatever URL we host it at, which version you are viewing; the repo is still the single point of truth for the specification text.

Not to undo the fine work with the specification subdomain, but are there good reasons for going with a separate subdomain for this, rather than to create a new 'specification' repo that uses the GitHub pages feature of automatically getting the specifications hosted under https://www.optimade.org/specification ? (Much like, I see that by accident we host the providers page also under https://www.optimade.org/providers ...; maybe we should turn that off.)

I initially tried to do this, but I think the corresponding URL would be https://www.optimade.org/OPTIMADE rather than /specification, which isn't quite as nice... Feel free to play around with the settings though.

[rartino]

@ml-evs

I initially tried to do this, but I think the corresponding URL would be https://www.optimade.org/OPTIMADE rather than /specification, which isn't quite as nice... Feel free to play around with the settings though.

Ah, but, is it crucial that the specification(s) webpages are built in a gh_pages of the main OPTIMADE repo, as opposed to another Materials-Consortia repo named 'specification'? I don't think functionality-wise it would be very different?