I’ve decided to start working on Laravel Breadcrumbs again…
redux – /rēˈdəks/ – adjective
Brought back; revived.
In October last year I decided to stop supporting Laravel Breadcrumbs, my most popular Laravel package, because I was no longer feeling motivated to work on it and it felt like the support / bug / feature requests were starting to pile up. The funny thing is several people have emailed me over the last 8 months to thank me for developing Laravel Breadcrumbs – more than ever did while I was supporting it – which started to motivate me to work on it again. The download count and GitHub stars also continued to grow, despite the clear warning that it wasn’t maintained. I’ve now decided to start working on it again, with the following changes:
- I won’t spend time & energy trying to help developers who can’t debug their own code. This was one of the things that annoyed and demotivated me the most.
- I won’t implement any feature requests I don’t personally want, and I won’t accept pull requests for features without a clear and high value use case – new features add complexity and additional maintenance overhead.
- I will try to fix bugs and make it compatible with new versions of Laravel – but only when I have the time and motivation to do so.
In other words, I won’t guarantee anything – it is free after all – but it will no longer have the giant “THIS PACKAGE IS NO LONGER MAINTAINED” warning in the documentation. Also, to make maintenance simpler:
- I won’t support old versions of Laravel and PHP any more – this made coding/testing harder and documentation more confusing. (I’ll probably release a new major version that formally drops backwards compatibility soon.)
- I’ve switched from Read the Docs back to a simple README file on GitHub. I think this is simpler to write and easier for others to contribute to.
- I’ve removed Travis CI and Coveralls, because I think I was placing too much emphasis on test coverage and actually making development harder. I’ll probably create more integration tests (using Testbench) and have fewer unit tests (using Mockery), so the focus is on the public API instead of the internal class structure.
Finally, I’m considering making it “Postcardware” like Spatie (or just “Emailware”), because it’s always nice to get positive feedback and I’m more likely to keep working on it if I do.