In-Touch / laravel-newrelic

Laravel NewRelic ServiceProvider
173 stars 48 forks source link

Update install instructions with full semantic version #41

Closed andrioli closed 1 year ago

andrioli commented 8 years ago

Using fully semantic version (i.e., MAJOR.MINOR.PATCH) to avoid break changes.

I suggest to use the full semantic version to guarantee backwards compatibility during composer auto updates (composer update). Note that even a minor change may introduce break changes since version for Laravel 5.1 (2.0.0) isn't compatible with version for Laravel 5.2 (2.1.0).

~2.0 allows anything up to, but not including, 3.0

Jalle19 commented 7 years ago

This doesn't do what you think it does. From Composer's documentation:

The ~ operator is best explained by example: ~1.2 is equivalent to >=1.2 <2.0.0, while ~1.2.3 is equivalent to >=1.2.3 <1.3.0. As you can see it is mostly useful for projects respecting semantic versioning. A common usage would be to mark the minimum minor version you depend on, like ~1.2 (which allows anything up to, but not including, 2.0). Since in theory there should be no backwards compatibility breaks until 2.0, that works well. Another way of looking at it is that using ~ specifies a minimum version, but allows the last digit specified to go up.

The only way to achieve what you're trying to do is to bump the major version of this library whenever Laravel/Lumen compatibility is lost.

andrioli commented 7 years ago

The Composer documentation says exactly what I meant...

The problem is that the Library is not respecting semantic versioning (introduced a break change with a minor change). ~ plus patch modifier in versioning will not allow minor updates.

Jalle19 commented 7 years ago

Looks like I misread the documentation myself. It seems that this would indeed work. Sorry for the confusion!

Jalle19 commented 7 years ago

Either way the major version should be bumped in the future to prevent this.

pleckey commented 7 years ago

I get the semantic versioning argument and agree, however with the speed at which Laravel moves and the changes in routing that seem to happen in every MINOR release, I'm thinking of simply having separate branches named for the Laravel version they support, as the code is starting to diverge (especially between 5.1 LTS and 5.4) more than I'd like to handle with tags.