-
Notifications
You must be signed in to change notification settings - Fork 0
Publish plugin #5
Comments
We eventually want a cli to publish the plugin but for a first step, it could be only the API, e.g.
|
I'll do the CLI after the API gets stabilized
|
I thought this would be the very first API? |
But the API I will do now |
|
This will be the first api, doing a cli now is not a great idea because the API is in development, and we have to change the cli everytime that API changes |
Can I add support for icons too? I mean, I already have to store files, so what's adding one more to the mix? |
Yes please. Let's add icons. |
I'll integrate this into the pipeline, so it generates the HTML from the Open API specs and then rocket serves it, but I'll do that later |
You can even test and play around with the API on your browser, which I think is really cool |
I'll also make a yank version system similar to what cargo does, probably you've seen the delete endpoint |
I'll store all the versions of the plugins so it would be cool if people could choose the version they want to download. People do dumb stuff and break their code quite frequently, so adding the ability to go back do older versions is important |
So, the design I'm thinking is that, plugins are basically containers that contain versions. Versions contain the plugin data like themes and the code. |
draft/preview plugin versions |
@panekj What do you mean? |
Do you mean like adding a option to mark a version as a preview release? |
yes |
i'm going to use semantic versioning on the registry, so what if adding a -alpha/beta/rc* tag to the version marks it as a preview release? |
But thinking well that can generate false positives/negatives, so its a trade-off, its easier to use, though it's not always reliable. |
TO simplify the implementation, i'll let the user decide whether its a pre-release or not |
Implemented: 5539616...9d53e35 |
The development of this issue is being made on #8.
The text was updated successfully, but these errors were encountered: