I was thinking on how to show that a package is compatible with Meteor 3.0 and show compatibility on Atmosphere. I was thinking to utilize versionsFrom in the packages settings for that.
So that when Meteor 3 is out, packages will add 3.0 to their versionsFrom list when they are compatible with that version. This would also apply for packages that do not need to make any updates in order to be compatible.
Then Atmosphere could pick it up and list that the lowest version of Meteor compatibility (lowest version in versionsFrom) and then other major versions and there could be a highlighted part that would show if the package is compatible Meteor 3 (depending on having the 3.0 in their versionsFrom). Next step would then be a deeper analysis of dependencies and so on, but I think this is a good first step.
So the guidance should be that if you are compatible with Meteor 3.0 with your package, you should have 3.0 in your versionsFrom.
Showing compatibility would be very nice. The implementation will need to be different since versionsFrom isn’t included in published packages - instead, it affects the version constraints of the core packages that are used by the package. I had left a comment here explaining it. Changing the implementation to compare the constraints on core packages with the versions of the core packages in the Meteor releases would work and be compatible with all packages, even those that don’t use versionsFrom or haven’t been updated to add 3.0 to their versionsFrom. Though doing it that way would be more complicated.
For my packages that support old Meteor versions, I find it easier to maintain and understand by using versionsFrom for the oldest Meteor version they support, and then manually add the version constraints for core packages that had a new major version since then.
versionsFrom doesn’t always limit the minimum Meteor version. Since it sets the constraints on core packages, it would be compatible down to the last Meteor version that updated those packages. Basically, versionsFrom tells Meteor to take the versions of core packages from the listed releases so you don’t have to manually write them yourself.
Interesting. It would be best if Atmosphere could detect the minimum compatible version, but I think that is not worth the effort, especially given how many clamor for complete move to NPM, so maybe just adding another variable to the package description that lists compatible versions could be a good compromise. The minimum version would be set from the lowest versionsFrom (or could be set manually) and then the maintainer could list compatible range. By default we could assume that it is compatible from the minimum version to the latest and if needed the package owner could update metadata with the range change to indicate if the current version is not compatible with the latest Meteor release, which could then cascade on earlier releases that don’t have any max release compatibility set. Major releases would then require explicitly setting that compatibility.
So let’s try some examples. First one where you define range:
Where if the maxMeteorVersion wasn’t present it would assume that it is compatible with all of Meteor 2 (but not 1 or 3). Since there is maxMeteorVersion it would show warning for Meteor 2.8 that compatibility might be an issue.
Compatible from Meteor 1.12.1 and all of Meteor 2:
Idea: could we use 1-2 visual badges for updated packages in the README.md™ to indicate for non-super-technical users whether the package has been updated to either ASYNC and/or 3.0 yet?
(Not a designer, obviously )
Because for me it’s not that clear currently how to find out for every package whether it has been updated or not…
What do you think? Would that be a nice thing to have maybe?
Hi, revisiting this because it sounds both interesting and important, but I didn’t get the nuances of the discussion, to be honest…
So… how could we tell whether a package has been updated to meteor 3 / async?
I think we could get into a Python2 / Python3 situation where the entire ecosystem will be split into Meteor 2 compatible packages (for example everything last touched before 2020/2021 basically) and new packages which have been updated.
I really think it would make sense to be able to tell which packages have been touched / updated somehow?
I’m updating a package and I want it to be 2.8 and 3.0 compatible. Should I leave api.versionsFrom('2.8') and indicate it’s compatible with 3.0 some other way or should I set api.versionsFrom(['2.8', '3.0-alpha.19'])? If the latter, once 3.0 is officially released, will I need to update it to api.versionsFrom(['2.8', '3.0']) or not?
Yes, it is the later. For now api.versionsFrom(['2.8', '3.0-alpha.19'])
Then api.versionsFrom(['2.8', '3.0']), but the caveat is that you will need to only use the *Async versions of functions and not have use an API that is breaking in 3.0 (there will still be few).
)