chore: filtering patches from docs deployment script

[signorecello]

Description

This change makes the script that runs before yarn build filter down the patches to the latest patch of every major.

Problem*

This script used to remove:

• Prereleases
• Nightlies (which are prereleases)
• "Aztec" versions

However, this would mean that every patch, as long as it was stable, would have its own docs deployed. This would lead to docs having three patch versions, which shouldn't even differ (they're patches, no breaking changes), like 0.19.1, 0.19.2, etc

Summary*

This change simplifies the script by removing some computation that was there just for debugging reasons. It also stops assuming all "aztec" versions are prereleases. And finally, it filters down only for the latest patch version.

Additional Context

Another way of doing it (which is how we're doing it now) is to just make all non-latest patch as prereleases, which is kinda annoying. With this change, it shouldn't matter.

[github-actions]

🚀 Deployed on https://657b908196878a0076966eda--noir-docs.netlify.app

[Savio-Sou]

It doesn't show our third-recent stable release v0.10.5 🤔

[TomAFrench]

It doesn't show our third-recent stable release v0.10.5 🤔

Likely a pagination issue on the github api due to the nightly releases.

[signorecello]

It only shows three versions, that's dev + 2... I think this is good this way, I believe there's no reason to support anything older than v17

[socket-security]

No top level dependency changes detected. Learn more about Socket for GitHub ↗︎

[TomAFrench]

It only shows three versions, that's dev + 2... I think this is good this way, I believe there's no reason to support anything older than v17

The issue is that nightlies are pushing all of the stable releases out of the api response. As time goes on then we'll gradually get fewer and fewer versions showing up in the dropdown unless we release new breaking versions fast enough to ensure that we have 3 on the first page of the response from github.

The way filtering is set up currently does "3 + dev" afaik as we're filtering the api response whereas dev gets added later by docusaurus. If you drop the limit down to 2 I expect that we'll get the same dropdown.

[Savio-Sou]

+1 concern isn't on v0.10.5 specifically, but to make sure frequent nightlies / pre-releases would not affect versions available on docs.

[signorecello]

I'm sure it is getting pretty much all the versions, it does pagination but we get versions all the way back to 0.7ish iirc.

It's the filtering that makes only the last 2 releases + dev show up 😊 but I can have a look tomorrow just to be sure before merging

[TomAFrench]

I only see releases back to 0.19.0 although this is just when opening up the endpoint in the browser so maybe if you're using an API key then you get more.

[signorecello]

So yeah seems like we're getting 100 versions per page, which is apparently not enough for 0.10.5. Here are all the versions pulled from the axios call:

And this is after the first .filter that removes prereleases, nightlies and stables:

Had a quick look and indeed, versions like 0.15.0 are not stable. We also remove 0.16.0 manually for some reason I currently do not recall. That leaves us with these two.

I'll make the change to pull more pages to filter, but I still believe it wouldn't be important to document anything below 0.17. Wdyt @Savio-Sou ?

[TomAFrench]

We also remove 0.16.0 manually for some reason I currently do not recall.

It had an unsafe merkle tree impl in the stdlib.

I still believe it wouldn't be important to document anything below 0.17. Wdyt @Savio-Sou ?

It's not so much that we need to go back to 0.10.5, the trouble is that going forwards in the best case scenario the longest time that we show docs for a particular minor version is around 3 months (before it's pushed off of the first page of the api response). I think that 3 months is a pretty short amount of time to display docs for a particular version.

[signorecello]

Makes sense 👍 Just updated the script to deal with 3 pages, which is enough to get ALL the versions since the beginning of time 💥

It will document v0.10.5, because why not It's not documenting v0.10.5 because I removed that version artifacts in #3778, so I'm removing 0.10.5 instead of creating them back from that tag

gtg @TomAFrench @Savio-Sou

[TomAFrench]

Let's delete versions.json. Happy to merge once that's done.