Add staging state?

[minhqdao]

As final packages are supposed to be immutable (except for some metadata maybe), I think we should have sth like a staging state (a simple field in the package like is_staging or is_final might suffice, or sth more sophisticated like a publication_state : "staging") where the package is uploaded and fully functioning but might be altered, swapped, or even removed. It acts as a beta phase before it becomes fully permanent within the database. I can just otherwise imagine that someone uploads a package which is buggy or has a typo and that'll stay in the database forever. 😣

On the fpm side, we could warn a user if a package is used that is still in staging mode. We can also warn the uploader that a package will become fully permanent and immutable if the he/she changes the package to "final".

[henilp105]

@minhqdao Sure, That seems to be a great Idea I think we should implement this @arteevraina , But the main thing to consider is that the user himself will also be a maintainer so he can delete/update the details of the package/version. We should surely implement this for namespaces. I will be adding a field to the packages collection.

[arteevraina]

As final packages are supposed to be immutable (except for some metadata maybe), I think we should have sth like a staging state (a simple field in the package like is_staging or is_final might suffice, or sth more sophisticated like a publication_state : "staging") where the package is uploaded and fully functioning but might be altered, swapped, or even removed. It acts as a beta phase before it becomes fully permanent within the database. I can just otherwise imagine that someone uploads a package which is buggy or has a typo and that'll stay in the database forever. persevere

On the fpm side, we could warn a user if a package is used that is still in staging mode. We can also warn the uploader that a package will become fully permanent and immutable if the he/she changes the package to "final".

Yes, this looks like a nice feature addition to me as well and It is also related to isDeprecated flag which we discussed here earlier https://github.com/fortran-lang/registry/issues/1#issuecomment-1359325853

[arteevraina]

@minhqdao Sure, That seems to be a great Idea I think we should implement this @arteevraina , But the main thing to consider is that the user himself will also be a maintainer so he can delete/update the details of the package/version. We should surely implement this for namespaces. I will be adding a field to the packages collection.

I think I understand namespaces as a domain in which the packages can be linked. So, two different packages with the same name can exist on the Registry under different namespaces (domains) and this makes things easy on the fpm side that no two dependencies with the same name and domain (namespace) exist in the project or something like that. But, I could not understand here what does publication_state has to do with a namespace. Maybe I am missing something here ? @henilp105

[awvwgk]

I think the other way around is preferable here, every upload is immutable, but can be removed if broken (yanked). Removal will retain the package for explicit dependencies, like on Crates.io or PyPI. Deletion should be an operation reserved for admins.

If staged or beta packages remain mutable, what does prevent someone to just upload all packages in the staging area and have them always mutable?

[minhqdao]

If staged or beta packages remain mutable, what does prevent someone to just upload all packages in the staging area and have them always mutable?

There should be in warning during build when a dependency is still in the staging area:

+ The package "xyz" is still in beta. It may get changed or removed at any time.

Identifying if a package is broken, however, could add additional work for maintainers who in some cases will need to decide whether a package should be taken down or not. I also like the idea of calling it is_deprecated as @arteevraina suggested because we aren't actually removing the package from the database. Then it is still retained for explicit dependencies. We should use an enum right away so we can add more states (we could differentiate between deprecated and broken, for example).

We could also think about automatically move an uploaded package from beta to stable after a fixed staging time period. During that time (let's say, 30 days), the package is fully mutable (with user warning in fpm), but won't be after that.

I just want an uploader to be able to upload a package, test it thoroughly via the official registry, send it to colleagues to let them try it and be able to take it down or change it before it becomes fully stable and immutable. The main ideas are to reduce maintenance work and having less "dead packages" lying around the registry.