Bouncer Versions Save

Laravel Eloquent roles and abilities.

v1.0.2

1 month ago

Bouncer is now ready for Laravel 11 🥳


Bouncer has long tried to maintain support for a huge matrix of Laravel versions, simultaneously. However, as the list of versions grows, it becomes untenable to support them all in a single codebase.

The commit to support Laravel 11 has over 2,500 lines of additions/deletions. The test suite was upgraded to PHPUnit 11, and now uses Workbench to run tests against a real Laravel app. Trying to do all that while supporting a huge matrix of Laravel and PHP versions is nigh impossible.

So this version of Bouncer, v1.0.2, makes a clean break: we now only support Laravel 11 and up. If you're using older versions of Laravel, you'll still be fine with Bouncer v1.0.1.


While contemplating this change, I wasn't sure whether to make this a major new version. It doesn't feel like a major new version, but is it a breaking change?

I asked on Twitter, and @michaeldyrynda helpfully pointed me to this pertinent article by @sebastiandedeyne: Composer, semver, and underlying dependency changes.

In it, he quotes directly from semver.org:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts.

In other words: since Composer will handle this correctly, it's not considered a breaking change. If you're not yet on Laravel 11, Composer will keep you on Bouncer v1.0.1, chugging along nicely till you're ready to upgrade.

v1.0.1

1 year ago

v1.0.0

2 years ago

Stable Release 🥳

v1.0.0-rc.13

2 years ago

This is mainly a housecleaning release, with two breaking changes:

  1. Levels were removed. They were too much of a burden on maintenance, and has actively hindered development on new features. With Bouncer's many features, such as allowing & forbidding permissions, broad model abilities, per-model abilities, and the powerful ownership model, the need for levels is now truly niche, and no longer worth the maintenance cost.

    They were purposefully never documented, and I've been saying in the issues for years that they will eventually be removed.

  2. Bouncer's checks, by default, now run after your policies and gate definitions. This gives your code precedence for all auth checks. If your code explicitly passes/fails a check, that will now be honored and Bouncer won't even run for that.

    This is actually what people expect intuitively, and has been a setting in Bouncer for a long time now. This release just switches the default.

    If you prefer the old order of things, you can tell Bouncer to run before your code:

    Bouncer::runBeforePolicies();
    

    This setting used to be called Bouncer::runAfterPolicies(), as it toggled the inverse. If you have that your code, you can now safely remove it.

v1.0.0-rc.12

2 years ago

New

Support for Laravel 9 :partying_face:

v1.0.0-rc.11

2 years ago

New

  • PHP 8.1 :rocket:

Fixes

v1.0.0-rc.10

3 years ago

New

  • Support for PHP 8.0 :tada:

Fixes

  • Support non-standard auth configs (#527, #528)

v1.0.0-rc.9

3 years ago

New

  • Support for Laravel 8.0 :tada:

Fixes

  • Syncing user roles should not affect other authorities with the same ID. #529
  • Fix Bouncer::canAny() method. #526

v1.0.0-rc.8

4 years ago
  • Adds a Bouncer::canAny() pass-through method to the Gate (#510).
  • When soft deleting a role/ability, pivot records are no longer deleted (#491).
  • Fix for when Laravel is set to use table prefixes (#508).

v1.0.0-rc.7

4 years ago

New

  • Support for Laravel 7.0 :tada:

Breaking Changes

  • This release finally drops support for older versions of Laravel. Starting with this release, we support Laravel 6.0 and up.

    If you're still using an older version of Laravel, you can continue using RC6. There are no known bugs.

  • Since we no longer support older versions of Laravel, we no longer need the getClipboardInstance() method (#505).

    There's an extremely low likelihood of this affecting you. This will only affect you if you were calling that method directly (why?), or if you ever had to manually resolve conflicts, such as:

    use Authorizable, HasAbilities {
        Authorizable::getClipboardInstance insteadof HasAbilities;
    }
    

    If you have code like that anywhere, you should remove the explicit insteadof precedence resolution, since that method no longer exists.