For over half a year at this point, there has been no new release of Ore. The last (non-hotfix) release of Ore was made on April 5th. As of today, I’m happy to announce that’s no longer the case. The latest release is now Ore 2.0.0-M1, released today 
.
Some history
So, why so long? Around April this year, I and the other devs decided that it was no longer feasible to maintain the old API. So we decided to replace it. The new API would be built to be much better and more performant. In addition to that, it was decided long ago that once a better API was built for Ore, Ore itself would use this API for it’s frontend. Around a month and a half later in May, we had most of the groundwork done for the new release. So, why did we first release now? Well, as any developer knows, it’s the last 10% of work that takes 90% of the time.
Highlights
But now that we finally have Ore 2.0.0-M1, what are some big things and changes? There are three big things I’ve talked about, again and again. I want to go over each of these, in addition to some lesser talked about things. These three big things are No more PGP, API v2, and, it’s faster.
No more PGP keys
I think this is the most anticipated thing of all, even though for us Ore devs it feels more like a footnote compared to the other changes. So what’s changed? So what does this mean? What it says on the label. No more PGP keys. They’re gone. How gone? So gone that there isn’t a single mention of PGP in the codebase.
Some of you have raised a concern about this. You liked some of the security that came from having this signing in Ore. Why not just make it optional? Because of the way it was implemented, it was mainly just security theater. We do want to implement something into Ore to pleas you guys later, but it will likely be optional, a bit more tedious to set up, and much more secure.
API v2
Before I talk a bit about API v2, I want to stress one thing. This is Ore 2.0.0-M1, not 2.0.0. That shouldn’t mean a thing for most of you, except if you’re going to use the API. The new API is still prone to breakage. If you want to make something that uses the API today, as much as it pains me to say it, you’re probably better off still using the old API for a bit longer. This is also the reason why it’s still going to be a bit before the real 2.0.0 release. This also means that if there’s something you don’t like about it, we still got time to fix it.
Next big thing about the release, and probably the most significant thing for us Ore devs, is the new API. The old API has been a pain in our back for a long time. In most places in the codebase, we have managed to get away from each page load doing tens to hundreds of requests to the DB (not an exaggeration). We’re really happy about that. The old API is the big exception to that. Most of the code in there is years old, and no one is brave enough to touch it (I tried and almost went mad). So, we did the reasonable thing, and threw all of it out the window, and started from scratch again. Along the way, we also threw out old concepts that likely won’t exist in Ore much longer, and redesigning authentication with the API. You can find the new API docs here. Ore OpenAPI specification
Ore itself has already started using this new API. Ore now uses the new API in all the places it can. We have also begun work on a new Vue frontend, which is what we will ultimately end up with. You can see the beginnings of this on the homepage, using both the new Vue frontend and the new API. This also means that you now finally select the page you want to go to on the homepage.
Speed
The third big thing about Ore 2.0 is that it’s just faster. Plain and simple. Pages should load faster from Ore. There should be fewer requests to get images when loading pages. Just loads of performance improvements all over the place. This isn’t just looking at pages where we’ve started to implement the new frontend either. We have also tried to reduce the number of redirects Ore uses (icons used to be a big offender here), and other small tweaks. I don’t feel it would be an exaggeration to say that most pages load probably twice as fast as they used to.
Smaller things
Next up, let’s talk about some of the smaller stuff that we haven’t talked much about
Project creation
First off, redone project creation screen. This has a few advantages I hope. First off, people need to be more aware of what their plugin id is. Secondly, this will allow your first version to be uploaded with the API. Thirdly, this will enable "draft "projects only visible to you for 24 hours. We had an issue about this at some point but closed it because it would be too much hassle. Now it works fine. It’s also much simpler for us to deal with in the codebase.
New things on the project pages
Next, let’s look at what Nucleus’s project page looks like on Ore 2.0. Most things stay the same, but some things have moved around, or might be new.
Toolbar, homepage and support
The first thing we might see that has changed is the toolbar. Staring, watching, and flags have moved slightly up, the download button has disappeared (more on this soon), and two new tabs have appeared, homepage and support. Homepage is obvious. Support can be anywhere you do extra support. I guess the most common example would be a Discord server or an IRC channel.
Promoted versions
The next big thing I want to focus on here is promoted versions. These are exposed both on Ore pages and in the API. So wait, now Ore has both recommended versions, AND promoted versions?! Why, what’s the difference between them? The short version is that recommended versions are the legacy solution that’s being phases out, and promoted versions are the new big thing. Recommended versions in Ore currently are error-prone and a pain to deal with. So instead, we’re replacing them with promoted versions. The box on the sidebar here is the new replacement for the old download button. We’ll probably refine their appearance and such, and expose extra info like platform, platform version and stability over time, but for now it’s just a basic box with links.
Ore will also display these in a small way on the front page. Here we can see that Nucelus supports Sponge 7.1, 6.0, and 5.1. Also, no more Sponge 7.1-SNAPSHOT :D.
So, what are the big differences?
Recommended versions:
- One single version (zero versions in error cases)
- Set by the user
- Dictates the definite version of the plugin (Shown tags on homepage, download button)
- Exists in API v1
Promoted versions:
- Up to 5 versions (a soft limit that we can easily change)
- Calculated based on tags (that are set by the user)
- Dictates the definite versions of the plugin
- One version per platform + version
- Exists in API v2
Other minor changes
There are many other small changes in Ore (watchers of projects, project keywords for better searchability, etc.), but I won’t go over them here. Go and find them yourself 
Some notes about future versions of Ore
Now that we’ve looked a bit at what is different from the Ore you guys used to know, I also want to talk a bit about where Ore is headed. Note that not everything here may arrive in Ore 2.0.0
More on promoted versions
Promoted versions as they exist in Ore today are kind of just placeholders in a way. Sure, they do roughly contain the information they should. Ore still uses the old recommended version in many places. Likewise, promoted versions are shown in a few places, but far from everywhere. A big reason why we haven’t switched entirely yet is that we want to make sure promoted versions are a good replacement before we replace recommended versions with promoted versions.
Let’s talk about channels
In short, channels are going away and are being replaced with a specific set of tags that developers can set when uploading a plugin. Think of how you set if a version is unstable currently. The advantage this has is that Ore can attach semantic information to these tags.
For example, when uploading a plugin, you would be able to choose between a set of values for the stability of the plugins
(These are not set in stone)
Stability:
- Bleeding
- Unsupported
- Alpha
- Beta
- Release
- LTS (Or something else)
Ore will then ignore any versions marked bleeding and unsupported, and prioritize more stable versions when choosing what version should be the promoted version. Our goal with this system is to give developers some control over what versions are shown to users while making it easier on Ore choosing these versions.
We also want to use tags like this for other places too, like for example release type. Maybe something like this?
Release type:
- Major rework
- Added features
- Bugfixes
- Hotfix
We would love more ideas from the community regarding this.