Release Channels and Package Status

[Digitalone1]

This started by this, but was also mentioned on Discord and sooner or later we should talk about how to implement it.

Packages on Pulsar could have different channels. At the moment there's only one (which is supposed to be stable), but in the future we could have more. So a package could have also a beta channel and, if I'm interested, I can switch to it and update the version.

Besides there's also the notification of the status of the package. In Pulsar the user is not forced to update the package, so if they want to do it manually, we could suggest them what to do. And this can be done signaling some problematic versions. If a version is unsecure or bugged and the author does not want to delete it, they can still tag it as unsecure/buggy, so the user knows there would be a problem.

Anyway there are a couple of things to note. This will need a big refactoring to the code and the database. But, I don't want to go soon into many details about the code and the database. I'd like to make some questions in helping to clarify how we start to design this new features:

• Which should be the additional channels?
  The current channel is assumed to be stable. So if the author wants to create more, what to do? Should they be decided by the publisher? Or should we make an enum [alpha, beta] and restrict to it (then add others in the future, listening to the feedback)?

• When a new package is published, which channel should be used?
  I suppose the stable, but what about authors that may want to release starting from a beta channel? Should we change the API? Or make a new one? What about making the publication of a new package declaring only a version and its channel, rather than downloading all the versions?

• Which should be the status tags?
  Same as the first question, but for the status tag. Should they be in an enum or we leave the authors the choice of what to use?

• What Pulsar requests to the backend?
  Which are the requests of the application? We have to know what it wants to design the server responses. Package Object Short/Full should be redesigned to support this new stuff.

There will be also other questions, but I will do them further ahead...

[confused-Techie]

@Digitalone1 Thanks for posting this question to get some of these ideas out there.

But here are my thoughts.

Additional Channels

These should be an enum. Since that's the only way I foresee us being able to sort semvers on each channel respectively.
I'd propose that we follow (At least for now) the Point Software Release Cycle. Meaning we should add the following options as enums:

• pre-alpha
• alpha
• beta
• rc (Release Candidate)
• ga (General Availability)
• stable
• lts (Long-Term Support)

Now of course we wouldn't require using all or any of these. But if a package used multiple then we would be able to cleanly support sorting through all of these as much as possible. Which would be sorted in this order (Earliest to Latest)

Default Channel

I'd say the default channel shouldn't change. A user used to publishing on Atom and Pulsar should see zero change in how they publish. They hit publish and it hits stable. Then I'd suggest CLI flags, which are converted into Query Parameters on our end can be used to purposefully publish under a different release channel, which should be the same methodology for publishing a specific version on a release channel.

For example to publish a stable version:

pulsar -p publish my-package

Then to publish an Alpha version:

pulsar -p publish my-package --alpha

So we wouldn't have to create any new endpoints or break compatibility with previous ones, we could just accept new query parameters, which, when absent results in the same expected behavior.

Status Tags

This might deviate slightly from the major discussion but I'd vote for the following possibilities:

• published
• latest
• deleted (or removed, can't remember which is currently in use)
• bugged (For a bug that shouldn't be reintroduced)
• insecure (For security issues within a package version)
• depreciated (For another sensitive issue within a version that we don't support natively. A catch all for any other reason we haven't thought of)

Requests to Backend

Really, like before I'd suggest we don't create any new endpoint, and instead use more query parameters. So essentially when a single package is requested you can use /packages/hey-pane and this will give you all the stable versions of that package. But then lets say you want to get alpha channels as well then you could use /packages/hey-pane?channel=alpha or to include all possible release channels /packages/hey-pane?channel=all. Now this isn't fleshed out, as I'd hate to support possibly endless query params, but we could even use something like /packages/hey-pane?channel=only-alpha or use /packages/hey-pane?channel=alpha&mode=exclude with this last possibility meaning the mode of showing release channels is to exclude by default.

Like I said that last point of showing only channels for a certain package isn't well thought out, so very open to suggestion. Potentially if a user only wants a certain release channel, then all could just be requested and filtered out client side.

---

Other notes:

Is there any special considerations that should be made with your most recent post to Discord about the possibility of easily sorting through semver extensions, in relation to this post?

Additionally, it's possible that in the future, we wouldn't require users to specify what channel they are publishing we could instead figure it out with JS before attempting to publish to the backend. But due to that being prone to issues, it's safer (at least for now, to require the user to tell us)