Whoho! Today, we’re celebrating the first aniversary of Random. Random has been our default style through the existence of the second generation of ModernBB (that includes, but isn’t limited to ModernBB 2.0, 2.1, 2.2, 3.0, 3.1, 3.2, 3.3, 3.4 and 3.5). Through the current design language was introduced in ModerrnBB 2.2, which was released November 30th, 2013. So yes, we’re also celebrating 1 year ModernBB 2.2.

A brief history
Random, introduced as Randomness 1.0, together with Kindness, Awesomeness and Radicalness, was the default theme of ModernBB 2.0. It was a major redesign and completely different from ModernBB 1.6’s Air design. However, we weren’t to happy with the design and thus, ModernBB 2.1 focused on doing it all over again. This release, Randomness 2.0, introduced the general structure of the design as you still get it today.

Randomness 2.1 however, the version of Randomness that contains the currently used design guidelines, was released with ModernBB 2.2, while originaly made for ModernBB 3.0, and made improvements to performance, brought a brighter design and made other major improvements. Randomness 2.2 was the ModernBB 3.0 release and mainly focussed on making Randomness compatible with the new ModernBB 3 features.

Randomness 2.3 was part of ModernBB 3.1 and introduced some ideas from Vanellope (the project, not the ModernBB version), resulting in a major design enhancement to the topic view (and we got good comments on that one). Due to the good comments, the rest of ModernBB couldn’t stay behind, and thus, Randomness 2.5, part of ModernBB 3.2, redesigned all other pages, still staying true to the Original guidelines from Randomness 2.1.

Random 3.0 was released with ModernBB 3.3, it wasn’t a major difference for the eye, through Random 3.0 introduced support for ModernBB’s new style engine. Random 3.1 would improve further upon with ModernBB 3.4, including support for the new editor and other features. Finaly, the current Random 3.2 also brought support for the new ModernBB 3.5 features, but no major changes where applied.

Random 4.0
With the upcoming update to ModernBB, we will celebrate Random’s 1st anniversary with a redesign of the styles. This includes the default styles Random, Kind, Awesome and Radical, but also Luna, Pinkie, Shy, Happy and Magic, which you can download from ModernBB.be. These styles will (for now) support ModernBB 3.4.1 and up (so if you’re running an older version but want to use these new styles, your in luck, through you should update).

These new versions of the default styles will also include Improved information about them (updated screenshot, new logo, etc.).

2014 has come to an end. And to be fair: for ModernBB, it was a rather awesome year. Let’s take a quick look at a year of work!

Last year, we ended with the development of ModernBB 3 beeing at full swing. We released 40 new version of ModernBB and Luna in the past year, the first one beeing the ModernBB 3 Alpha 1 (core 0.0.30.1534). During 2014, 5 development releases of ModernBB, 6 pre-releases of ModernBB, 22 stable ModernBB releases and 7 development releases of Luna followed. The most recent one beeing Luna 1.0 Preview 2 DEVED (core 0.2.3478), earlier this month. And later today, you’ll be able to enjoy Luna 1.0 Preview 2 NEWED (core 0.2.3573)!

40 new versions is a lot. During 2013, we only released 23 versions of ModernBB. Note that ModernBB came to existence in April 2013 through, and that the real development actualy kicked of in late June 2013. So, on avarage per active month, we have released a lot more releases last year.

But releases aren’t what matter. Neither are downloads, through we’ve seen some realy nice numbers the past year! We closed of 2013 with 2045 downloads in total, making an avarage of 227 download each month since April. 2014, however, closed of with 11.780 downloads in total, making an avarage of 811 download each month. December 2014 was our best month up until now, with 1309 downloads. This means that, if we do not shrink in downloads, the amount of avarage downloads can be doubled during 2015 (let’s hope even better!). 2013 to 2014 was over 3 (almost 4) times more download per month!

But like I said, numbers doesn’t matter. Well, there is one number that does: the number of happy people. And we hope that we did make some people happy with all the work that is beeing done to ModernBB 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7 and Luna 0.0, 0.1 and 0.2 during the past year. A lot of features have joined the fun since last years final 2.2 release. And in fact, a lot of features are joining right now since the 3.x branch in Luna. Next year arround this time, I hope to be looking back at a beautiful Luna 1.0 and Luna 1.1 release (yeah, only 2 major releases planned for next year, 3 if you count ModernBB 3.7 (but that’s planned to be not such a major release) 4 if we might get to Luna 1.2, it feels weird!).

Well, I wish you a Merry Chrismas (a little bit late, but I already did this on Twitter too) and a Happy New Year! Enjoy the fun! I’m out for this year!

Last year, we released the 6th big update to ModernBB 3, with Luna in development however, what will be next for ModernBB? Will there be a ModernBB 3.7?

Well, to kick off. We plan to put the final release of ModernBB into a LTS release, similar to ModernBB 1.6, which got 6 updates (1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5 and 1.7.0), it will be supported for over a year. Especialy for security fixes, we will continue to support ModernBB into the future. However, only the last one, the big question is: which ModernBB release will be the last one?

I didn’t plan a ModernBB 3.6 release at first, but due to 3.5.3 becoming to big, I decided to do it anyway. With this new scheme, I do hope that ModernBB 3.6 won’t be the last major update to ModernBB. A ModernBB 3.7 is already in the planning. I’ve decided to not continue the idea I had with ModernBB 3.4 and 3.5 to release new features in the smaller patches, instead, these will be part of ModernBB 3.7 instead.

ModernBB 3.7 won’t be a big update. In fact, it might be just bug fixes, I’ll try to get some small features in there. I hope you guys understand that ModernBB isn’t my focus point anymore, Luna is. Anyway, ModernBB 3.7 will come, and unless we release it before Luna, it will be our final minor version jump. Otherwise, ModernBB 3.8 will be released. Why do we need a minor version bump after Luna? Because that would be our LTS release. So, if ModernBB 3.7 will be released after Luna 1.0, it will be ModernBB 3.7 LTS. If before, it will be ModernBB 3.7, and we’ll release a ModernBB 3.8 LTS after Luna (or perhaps the same day). In such a case, 3.8 will be bug fixes only.

So today, I discovered that there is a Wikipedia article about ModernBB (which also covers Luna). Awesome! Thumbs up for the guy that’s keeping the information on it up-to-date. Anyway, I decided to read through the whole lemma, and then, I came across this:

Similar to other software, like WordPress, main releases are named with code names. However, the logic used for ModernBB’s code names is unknown. Some releases share the same code name.

It sure knew to steal my attention. Why? Because it’s right. There is no logic in the ModernBB codenames. Will there be any kind of logic in Luna codenames? Probably, but remember, they are what the name says: codenames. Nothing more, nothing less.

ModernBB Codenames
While ModernBB 1.6 is called Blythe, it didn’t had a codename until ModernBB 2.0 was named Zoe. Both codenames came from the same source: Hasbro (that big entertainment company, you know, like Monopoly and stuff). 1.7 just took the 1.6 codename due to it not being such a big release. However, releases being small isn’t the only reason we stick to a codename. 2.1 and 2.2 where both named Zoe, too. There is no reason for that naming convention.

ModernBB 3.0 was named Odd. Because it was version 3, and uneven number, which is also called “odd”. Also, “Odd” is a name in some countries. ModernBB 3.1 and 3.2 where both named Mellow. These 2 releases sharing a name, did have a reason. Both releases putted the focus on revamping the front-end design. Its codename wasn’t ment to be the word “mellow”, through. It actualy comes from “marshmallow”. But we thought that was to long and shortened it to “Mallow” and then we switched the a for an e. I didn’t even realize at the moment it was an actual word.

ModernBB 3.3 was named Vanellope, after the Vanellope project I did in the months prior to it, of which it also got a lot of code. Anyway, that project’s name on its own was from Wreck-it Ralph, a Disney movie. One of the characters was named “Vanellope von Sweetz” (or something). ModernBB 3.4 was named Neon, and at that point, we did plan to introduce a logic in naming our releases: after the elements. Didn’t happen, through. The next version, ModernBB 3.5, was named Kate. ModernBB 3.6 and 3.7 are both named Blue. We just took names, there really is no reason behind these names. 3.6 and 3.7 share the same name because we don’t think it’s worth it to give it new names.

Luna Codenames
Luna continues to use codenames. Aero is an example, the codename for Luna 1.0. “Luna” as a name itself was a codename until it became our final name. We currently call our 1.1 milestone Luna 1.1 Bittersweet Shimmer. Another update, that currently doesn’t have a version number is Luna Denim. There is an updated planned in between Bittersweet Shimmer and Denim, so that’s going to be something with a C. Anyway, for the people that didn’t notice it: Aero, Bittersweet Shimmer and Denim are all colors. In alphabetic order. So there you have our logic. Finally.

Yesterday, we’ve closed off the Preview 3-stage of the Luna development, now, we’re working  on the first Preview 4-release, for which we’ve planned 3 updates. And than comes Preview 5, perhaps better known as Luna 1.0 Beta 1 (Luna v0.5). Why are we talking about Preview 4 and 5 this time around and not just 4? Let me explain:

First off, with Preview 3 Update 2, we kick off our weekly updates. This means that next Saturday, you guys will be able to enjoy Preview 4 already, we’ll release a new build of Luna every Saturday until we get to the final release. With this, we like to indicate that the now +8 months of Luna development are coming to a close. We’re left with 10 more previews (Preview 4, 4.1, 4.2, 4.3, 5, 6, 7, 8 and 9), through we might add a couple of additional previews. Either way, Luna 1.0 is now set for a 9 May 2015 release. Get hyped!

Final features
Preview 4 and its 3 updates will be all about finishing off the features we’ve included in the previous previews. Some other small additions might make it into the software, but don’t put your hopes on it. At this point, we start stabelizing our code, getting everything ready for translation, adding Random 5, and more. It’s not for now, but when we hit Preview 9, you’ll see us remove a couple of developer codes (like the “Core” message in the Backstage and all information in About about Preview-updates).

Further, we’ll be working on improving Sunrise and Sunset, extending the Notifications (the actions you have to do that will trigger notifications) and so on. Something else that is now on our main radar is the documentation, and while Preview 3 Update 2 already comes with a first draft of the documentation, it’s far from finished, and thus, more is coming. Finally, you’ll see us fix a faire amount of bugs.

When Preview 4.3 (“Preview 4 Update 3″) is released, we’re going in to our final week of feature development. After that, we’re on a feature freeze that will bring you guys Preview 5, perhaps better known as Luna 1.0 Beta 1 or Luna 0.5 (but we’ll officially continue to name them “Preview”, both betas and release candidates). Preview 5, 6 and 7 will all focus on finishing the new features, but they will mainly fix bugs. Preview 8 will be our first release candidate and with some good luck, Preview 9 will be our last. Followed by Luna 1.0 some time after (we’ve currently planned a week between Preview 9 and Luna 1.0, but we do not expect it to take that long).

End of the line, or road, pick what you prefer
And with that, the end of the road is in sight. I can see it, it’s still a distance, but it’s there. And we’re closing in. Finally. And what’s at the end of this road? Well, a brand new one. Bittersweet Shimmer Avenue, yeah, let’s call it that. If that doesn’t ring a bell, I’m referring to Luna 1.1. Guys, we’re coming close to the end, it was an amazing ride, and I hope you all are ready for the next one, because Bittersweet Shimmer isn’t the only road over there. Not even close.

While we’re still in the Preview 3 stage for Aero, when it comes to features, the development of our very first release is drawing to a close, with the expected final release in May, which makes up for 10 months of development and already over 800 commits to the core since the start. Either way, we’ve talked about it in our last blog post: we’ve planned more stuff. Let’s talk about that.

Aero – 1.0
Aero is, as you know our first stable release. We’re currently hard at work on it, and our weekly releases prove that. We’ll continue this schedual until we reach our first stable release. Either way, it’s a major improvement over ModernBB.

Bittersweet Shimmer – 1.1
Bittersweet Shimmer is going to be our first minor feature update to Luna. It will go by the number of version 1.1. Our main focus will be on improving upon the changes made in Luna 1.0, and we expect it rather quick after Aero is released. Do not expect much new features in version 1.1. You, however, can expect the kick-off of some major changes for later versions. This will also be the first Luna release to be developed with our new Git-structure. We’ll also be more specific in ticket items.

Cornflower Blue – 1.2
A couple of days ago, we’ve given our C-update a name: “Cornflower Blue”. Cornflower Blue will introduce a major revamp to the installer and update mechanics of Luna. These 2 systems are set to become completely rewritten and modular from the Luna core. The new components (as they will become components) will be released under their own license, the MIT license, that is. They will be completely separate from the original Luna core, and are our first steps towards a brand new core, which we like to call Edge. Further Cornflower Blue will introduce other small changes, but more on that later. As we follow semantic versioning, this will be Luna 1.2 and this update is planned for fall 2015.

Denim – 2.0
Next up is Denim. This will continue the work we did in Cornflower. But not for the installer and updater. No. You’ll see our Backstage being rebuild from scratch. A thing we’ve already started working on. Just like the installer from 1.2, the Backstage will become a separate component, as modular as possible, and released under a new license – again MIT. This will leave only the Mainstage behind on GPLv3, something we will fix later. Denim is supposed to introduce support for plugins in the Backstage (not the Mainstage). This major revamp of the Backstage will bring us to Luna 2.0 (as semantic versioning requires us to do so).

Emerald – 2.1
Our final planned update for now is Emerald. This update will have the same function to Denim as Bittersweet Shimmer had to Aero: it’s a minor all around improvement update. And thus we’ll probably go with version 2.1 for it. This update will focus on improving Edge (the name of our core for the installer, updater and Backstage by then). It’s currently planned to be the first update for 2016.

Early communication is good communication
So now you know what we’ve up to our sleaves. With Aero, Bittersweet Shimmer, Cornflower Blue, Denim and Emerald, we hope to keep ourselves buzzy for a while, and we hope to keep you guys happy for a while, until we’re ready to go to Luna “F” and beyond. And I guess that after reading this post, you guys might know what our plans are for the next major update after Aero (Luna 1.0) and Denim (Luna 2.0). On the other hand, note that codenames are not related to their respective version, and only in order of the releases.

We’re talking this early about our plans – which are subject to change – because we think that it is important to include our community in the development process as early as possible, so that’s what we do. And now, back to the development table for Aero.