I quietly released it over the weekend, and I’m glad I did. I already had a bug report and have released v1.0.1 to fix it. :D
The last few years of working on Marionette have been tremendously fun, exciting, frustrating at time, and have provided much more work and opportunity for me than I had ever imagined. I started this project out of need, and hoped that it might help a few people out – at least show them what could be done and give them ideas on how to do it. I never expected that this project would have 1/10th the number of stars it has on Github, or that this project would lead to working with dozens of amazing companies, travelling around the world, create new friendships, and land me some awesome speaking opportunities on podcasts and at conferences!
There’s a ton of new things that have happened since I started the 1.0 release candidates. And actually, going in to “release candidate” model was probably the worst mistake I’ve made with Marionette, so far. I had far too many breaking changes, far too many times for it to really be a release candidate series. But things are stable now, and have been for a bit. There were a few additions and breaks in this release, some of which came from dependencies.
Backbone.Wreqr is an integral part of Marionette and helps to provide a lot of the communication infrastructure for scaling applications.
In the latest release of Wreqr, I’ve renamed “addHandler” to “setHandler” for all Wreqr objects. There was confusion around the name “addHander” as it implied the ability to add multiple handlers. Since none of Wreqr allows multiple handlers for any one registered name, I changed this to “setHandler”. Anyone updating to Wreqr v0.2.0, along with Marionette v1.0.0, will need to account for this.
I’ve also made the commands somewhat persistent when there is no handler currently registered. Several people noted that they were running in to situations where a command needed to be executed, but due to the order of module loading being unpredictable, the handler wasn’t there. To fix this, a command can be executed whether or not the handler is available. As soon as the handler is available, the actual execution of the command will take place. Commands will persist in memory, for the life of the page. Refreshing the page or navigating to another page will destroy the not-yet-executed commands.
One of the most requested features in recent times has been the ability to add and remove regions from layouts. I set out to solve this and realized that half of the code I needed was already in the Application object, and the other half was in the Layout object. So I consolidated most of this code in to a single object called RegionManager. Both the Application and Layout now use a RegionManager to manage their regions. This allows a more consistent way of managing the regions, and provides all of the add and remove functionality that is needed, on both.
WOOO! STICKERS!!! :D
You can order yours from DevSwag. They are providing order management and fulfillment for stickers, for Marionette and many other amazing open source projects.
Semantic Versioning: A Goal
I have a goal, moving forward, of using Semantic Versioning for the version numbers. I don’t think I can promise perfect semantic versions, though, for a few reasons. First off, this is my first project to hit v1.0. I know I’m going to make mistakes and screw up some little detail here and there. But for the most part, I plan on following semver. Secondly, and more importantly, though, Marionette relies on other libraries which have their own release cycles. Sometimes releases coincide. Other times they don’t. Sometimes they break Marionette, other times they don’t. This will make it challenging to follow semver.
There are still more than 50 tickets open in the Marionette repository, and a lot of things that I want to do to help re-stucture some of the ugly parts. I want to tear apart Modules, for example, and create separated namespacing, sub-applications and components. There are a lot of other feature requests and issues reported that need big changes, too. I’m looking forward to where Marionette will head, and hope to continue to build a strong community around it – including a more active core contributor team.).
Yes, it’s the grammy-award speech time! Someone start the “wrap it up” timer…
I owe an especially large thanks to Jarrod Overson, Matt Briggs, Brian Mann and Tony Abou-Assaleh. These guys have been a great core team to bounce ideas around with, to help out with issues, and provide needed support and feedback. And to Ruben Vreeken for all the work he puts in to the Google group, answering questions. :)
Marionette wouldn’t be what it is without the amazing contributors. Everyone that has contributed in any way – answering questions in the google group, sending issue reports, ideas, pull requests, writing blog posts and articles, screencasts, and talking at user groups and conferences. I’m still and continuously amazed at how much has been done in the community with this library. Thank you all!
And thank you to all of the awesome people building apps with Marionette. Projects like Halo Waypoint, Redbull Music Academy, and StubHub are among the most widely known systems built with Marionette – then there’s the three error reporting / analytics tools: AirBrake.io, RayGun.io and CrashLytics. But there are so many more out there, still It’s been awesome seeing Marionette in all these places, and I’m looking forward to seeing where it goes from here! :)