One thing that would have been a very cool idea would be to rename the package name of those supported packages with for example MCP so in a second everybody know which are “officially” supported packages.
mcp:simpl-schema
mcp:roles
…
I know it means that, for existing project, they have to remove/add the package but for the new comers and for everybody, it would have be a great signal that those packages are officially supported and can be used without worrying.
Today there’s soooo many deprecated meteor packages that it’s a mess to understand what’s working and what’s not.
(of course, we can keep the name of the old package and the creator name in a #history part of the package readme to reward the effort of those guys who created those cool packages).
This was discussed in the initial conversations when Meteor Community Packages was formed, and iirc the thought was that it would create too much confusion and fragmentation, so we should keep packages published under their original namespace if possible.
For me it still looks like a workaround to more appropriate measures directly in Atmosphere/Packosphere, perhaps a green badge or something else for easy visual grepping. Perhaps even making old packages “opaque”, or something like that. This could be a small PR instead of a long manual process.
On Atmosphere, we have verified accounts and organizations marked with a blue badge for the packages they maintain. Initially, we only checked package authors, but now we also verify all maintainers of a package.
For deprecated packages, there’s an icon to indicate that. These features are already set up, and we can build on them, @leonardoventurini.
However, this doesn’t help with Meteor 3.0 packages either. I remember @storyteller started a discussion about it, and we can revisit that now that Meteor 3.0 is out.
Not to hot about all the work doing with this. Also the org we have for MCP is communitypackages, so we would have probably to start with a new org. I think it is just matter of improving the guides.
