More version increments to avoid dependency issues

[Cervator]

The reasoning block is great

The two todo sections read a little confusing / overly verbose to me, might be better with examples rather than versioning math.

Especially something like

It sets the maxVersion dependency field of all dependent modules to 0.x+2.0 (= compatible with 0.x+1.*)

Not entirely sure what is going on there. If we make an API breaking PR we increment minor by one. By the natural behavior of gestalt-module a dependent would no longer accept that version. So I guess you're saying if we want to go out of our way to validate the dependent as compatible we'd increment its maxVersion - but wouldn't we just do so by +1 not +2? So it matches the version being released.

I'm hoping to avoid / automate as many version bumps as we can, lest GitHub get too chatty with pure version bumps. I guess that may be more of an issue in the 0.x.y days tho

More lenient Gestalt would be helpful too, so if maxVersion is exceeded the user gets an option (with disclaimer) to use it anyway.

 

[Florian]

@Cervator: Thanks for the review.

I added a section about how to specify a dependency.

When there is just a minVersion specified there is implicitly a maxVersion field with an incremented minor version number (as described in that new section).

e.g. when there was a minVerison=0.54.0 field, then there was implicitly also a maxVersion=0.55.0 field. Thus when there was just a minVersion field with the value 0.54.0 and the module is also compatible with 0.55.0 then a maxVersion field with the value 0.56.0 needs to be added.

Thus if old minVersion was 0.x.0 then the maxVersion field needs to be set to 0.x+2.0 if the moduel is also compatible with 0.x+1.0.

Once the stuff is automated we can propably greatly simplify the TODO lists.