search

Tucker-Eric / EloquentFilter

An Eloquent Way To Filter Laravel Models And Their Relationships
http://tucker-eric.github.io/EloquentFilter
MIT License
1.72k stars 120 forks source link

Update composer.json #48

Closed Dylan-DPC-zz closed 6 years ago

Dylan-DPC-zz commented 6 years ago

Laravel doesn't follow semver. So having ^5.x, 5.* or >=5.x will mean that composer will install a future version even though that version breaks the package.

Tucker-Eric commented 6 years ago

As of now we haven't run into a future version breaking change. I think I may want to approach this the opposite way in leaving it as is and then applying a version constraint if there is a future breaking version instead of updating the dependency versions after every minor release.

Dylan-DPC-zz commented 6 years ago

The problem is that composers will install it for your users and if it breaks they wouldn't know that the package isn't supported with the corresponding laravel version.

Tucker-Eric commented 6 years ago

I'd rather keep this package maintained to assure compatibility instead of bumping the composer.json for every Laravel minor release.

Dylan-DPC-zz commented 6 years ago

So you don't mind your users installing the package and then seeing it crash because of some breaking change?

Tucker-Eric commented 6 years ago

I very much mind that which is why I actively maintain this library that is used across multiple production applications I develop.

What I don't want is users not being able to require this package due to a minor version not being defined in this package's composer.json. So when 5.6 is released we won't have to release a version as would all the other packages you have submitted this same pr to would.

I can assure you, as this package is actively developed if there is a breaking change in any future 5.* Laravel version we will create a new version to accommodate it before that version is released.

I appreciate your proposed PR but will not be merging it at this time.

Dylan-DPC-zz commented 6 years ago

What I don't want is users not being able to require this package due to a minor version not being defined in this package's composer.json. So when 5.6 is released we won't have to release a version as would all the other packages you have submitted this same pr to would.

Exactly that's the point. You release support for a new version only when you know it won't break. I know you will create a new version if anything breaks but it is not easy to spot breaking changes which means someone will have to go through the torture first before the update happens.

I leave that to you.