Every Meteor release includes a version bump for all core packages (this is also the commit that is tagged as the release itself, AFAICT), regardless if anything actually changes.
This causes new versions to be downloaded for all of the used core packages even if nothing changes.
In case someone (like me) maintains a local fork of some core packages, this leads to 2 issues:
I have to match the fork version with the released version. This becomes an issue when I have multiple projects with different Meteor versions and the packages are symlinked to a main working directory.
It makes it more difficult to figure out when something actually changes or this is a “blank” version bump.
I am wondering what is the purpose of this (having a dependency on an explicit package versions, I guess) and whether it is really necessary.
Is there a better alternative to this approach?
Is there a way to maintain a fork to a core package without experiencing this pain?
Oftentimes there’s a dependency bump. So pkgA depends on pkgB. B gets updated with new code, and moved to a new version. That will cause A to need a dependency bump to require the latest B package, even though no code in A is changed. That’s the cause of a majority of the minor version bumps. Not sure there’s any way around.
I’ve been wondering about the meteor-tool as well. If we make a modified meteor-tool, and start porting commands from StarryNight to the tool, what happens when changes don’t get merged into core and there’s a new meteor-tool release? Is it even worth it to try to put together PRs on the meteor-tool itself with additional commands and utilities we regularly use and merge them upstream?
I’m not sure that’s the case here, although I do remember coming across this several times.
IIRC, the expectation is to bump the patch version whenever one of the dependencies changes its minor version (or major version) (in any case of dependency API change) in order to “signal” it is compatible with the new version (through the .versions file, I guess). I am not really a fan of this, though, as this creates a lot of cascading versions and I much prefer the npm way of doing this.
This kind of goes against semver, as when you depend on v1.x.y, nothing should break while the dependency remains in the same major version. I can only speculate that MDG don’t trust the community (and perhaps rightfully so) to be strict about their semver or about package code not using implementation details/private code from their dependencies, or this could be a side-effect of the way packages are built for Atmosphere.
It seems that MDG is bumping the versions of all 147 packages on each release, even if only very minor changes were made between RC releases. It also seems that all of the version changes are to the patch segment.
Interestingly, this across-the-board bump did not happen in the latest (sub)patch releases (1.3.2.3-1.3.2.4),