dependent gem versions should depend on major version only

[catmando]

otherwise in future you will have REACT::VERSION = 1.2
then you upgrade to 1.3 for some minor thing
and now all other gems have to be re-released even though nothing has changed in them.

[janbiedermann]

now a user reports a problem. to check you need to know all versions of all gems, maybe, depending on the depth of the problem, and verify.

I prefer the rails way here, rails 5.1.4 is what it is, even some gems didnt change, but its "a well defined entity"

First option: Likewise "hyperloop 1.0.1" for everything being 1.0.1

Second option: But image "hyperloop 1.0.0, hyper-operation 1.0.2, hyper-react 1.0.3, hyper-mesh 1.0.5 ..."

Now a problem report:

• Something doesnt work

What version do you use?
First option:

• hyperloop 1.0.1

Second option:

• Well, errm, hyperloop 1.0.1
  Ok, cool, please list the versions of alle the gems involved ...

Further on, reproduction:
First option: to reproduce, give me your peace of code, i run it against 1.0.1

Second options: to reproduce, give me your piece of code, and i have to install the exact gem versions of the user and then i can run it

Further on, solution:
First option: Fixed, just install hyperloop 1.0.2 -> new tested set, well defined entity

Second option: make sure to include the following gems with the following version ....

Keeping them all synchronized makes support much easier. Yes, some gems sometimes are released with no changes, ok, but thats not the issue. The benefit of reducing the supported set (varieties of gems and versions), reducing complexity, makes support and development easier.

Imagine 1.0.0 going to 1.0.21 individually, the supported set will explode and problems appear, that are non issues, if the supported set would be clearly defined.

[catmando]

I think there is a difference between dependency and how things are released.

Rails AFAIK does not FORCE you to keep all of its sub-gems in sync. That is all I am saying.

The problem is from a production stand point, you get into situations where you need to take some patch to a gem, but that is all you need. You don't want to risk (even though the risk is small) taking a whole bunch of other gems. If we lock each release of hyperloop to a specific set of gems then you can't do this... I think it would be very bad, and to my knowledge is not the way rails works.

On the other hand while developing on edge it certainly makes sense, because stuff is changing, and we want accurate feedback, so that is why edge is one way (locked to specific versions) but release is not.

[janbiedermann]

I understand your concern, i agree, if somebody wants to run production like this, the versioning needs to be relaxed.