Mike Bronner has recently launched a new web app, Laraver.xyz, that monitors the public Laravel repository and notifies you of you any changes. This way you can stay up to date with even the smallest of changes and learn more about the core in the process.

After signing up you will be shown an overview page with a list of all changes in the current version.

Clicking on one of the files brings up a diff of all the modifications and can add your own annotation:

Annotations here are driven by the community and are then used to generate a friendly change log:

This is a big advantage to just viewing the changes on GitHub. The annotations let you see the intent of the change and answers the why of the change.

I had a chance to ask Mike some questions about this new endeavour and below is the question and answers:

What made you decide to build LaraVer?

When I started using Laravel, I had years of experience in procedural PHP (started in 1999 with PHP 3 I believe, up until about 2010, when I shifted my focus temporarily to computer hardware), but I found delving into the innards of Laravel seemed daunting. it took me over a year to become comfortable looking at core Laravel code and understanding how to navigate through it comfortably, as well as understanding what it does. But to use Laravel effectively, it is so important to understand its inner workings!

That requirement, and Laravel being updated so frequently, I figure I want to see what changes are made in the code, to see what the features are, instead of relying on outside blog posts that discuss major changes. To me combining the changelog functionality along with the code changes are the perfect way for me to inform myself as soon as a new Laravel version is released.

Now, the major feature with LaraVer is that anyone can participate! (I know I haven’t really pushed that aspect, and It’s probably not immediately apparent.) I purposefully did not want to put the changelog or diff availability behind a pay-wall, to foster community participation and collaboration. I also believe that community-sourced information and knowledge should be free. As such I chose to only charge a minimal fee for the notification service, which will notify you via email, SMS, or desktop notification, for any release-level you choose. (Notification preferences are extremely granularly configurable.)

Are you planning on including other Laravel components like Cashier, Elixir, etc?

Absolutely! Laravel Framework is the proof-of-concept project, both to determine technical implementation (iron out wrinkles, optimize processes, etc.) and evaluate user adoption. After this, I plan to expand to all official Laravel components. In the future I also plan to make this available for any projects, and even for use in private repos as a way of creating and managing changelogs for teams.

How long did it take you to go from idea to deploy?

I want to preface this by saying that profit is not the main motivator for this project. Instead, I wanted to challenge myself to start publishing any projects that I find useful as SaaS’ going forward. What I want to do here is expand my capabilities in running a SaaS, going through advertising and customer acquisition exercises, and working through the pain-points in spinning up a SaaS. The smaller the projects, the smaller the risk, so this is a perfect starter-SaaS where I don’t expect to make any money, although I would like to break even.

Back to the original question: I was able to bring this projects to life within 7 days. I purposefully set the goal to quick go-live with an MVP, then iterate additional functionality afterwards. This approach has many benefits, and I think little to no drawbacks: immediate user feedback, quickly identifying pain points and ironing out wrinkles that come up when going live on a small project. This allows for agile response to user issues. Once those are corrected, new functionality can be added, and iterated on according to user feedback. This way user-impact is usually very minimal and the users see improvement over time.

There are some features I still have yet to implement, such as moderating user contributions, gamification of the process to allow for leaderboards, and awards, and managing multiple projects.

What was the biggest challenge in building this?

I think the biggest challenge was getting Apple Desktop notifications to work. They require a special certificate issued from Apple to work, and also require a live SSL-cert to run. That means that the developer is essentially forced to develop on the live server, which I found extremely tedious. What I did was work on a page that was not listed in the menu, or could not be reached from any link in the app. Once I ironed out the functionality, I implemented it on the live pages in the app, and all was well. But I spent 2 days trying to get those to work. :-/

The most interesting aspect was evaluation code changes and presenting them. That was a lot of fun. The entire code base is evaluated locally on the server, and the diffs are then saved in the database. These diffs are then presented using custom Vue components. I really enjoyed working on that aspect. There were some challenges in Vue that needed to be worked through because the edge cases I encountered weren’t necessarily documented in the user guide, but the community forums were extremely helpful.

Source: Laravel News