Change Is Coming

It’s painful, but it’s the truth: major versions need to happen.

Let’s be honest, you read the title about a new major version and immediately broke into a cold sweat. Within seconds, your head was filled with a steady stream of questions:

• “What changes are being made? Will I even like the changes? Do I need these new features and/or changes? Are features being removed? Should I stay with the current version?”
• “Are there new requirements? What are they? Can my server run the new system?”
• “What about my data? How much of it can I migrate over to the new version? Will I lose any of my data?”
• “What will happen with all my MODs and skins? How much work will I have to do to get things working just the way I like them again?”

These are all legitimate questions, but this isn’t about answering those questions. Answers will come in the future as things are fleshed out and the development progresses. What this is is more of a philosophical discussion about major versions as a precursor to talking in greater detail about what is changing and (in some part) why those things are changing.

So back to the opening statement: major versions need to happen. But why? Why are major versions a necessity, and in the case of Nova, why am I going to be breaking all sorts of things in the name of “progress”? In reality, there are a couple of major reasons:

Fix Architecture Mistakes

I’ll be the first to admit that there are some curious architecture decisions in Nova 2. Some of those are a product of the framework, but others just stem from my inexperience in 2007 when Nova development began in earnest. When I talk about architecture mistakes though, I’m not just talking about the file structure (though that’s changing too), it also relates to how controllers are put together, how data access is handled, how data is validated, how events are handled, and much more. Every single one of those things came under scrutiny as I began to look at the future of Nova. In some cases, those things are broken in the current version, while in others, the architecture doesn’t even exist.

Account for Changes in the Ecosystem

PHP has come a long way since 2007 when Nova’s development began, but Nova hasn’t evolved along with PHP. It isn’t realistic to think that every time a new version of PHP comes out that Nova will be updated to use all of those new features. Shared hosting makes it difficult to adopt new language features quickly. Hosts don’t want to rock the boat too much, which is completely understandable. That alone ties my hands when it comes to utilizing new language features, but the fact of the matter is, today, Nova doesn’t use a language feature that’s newer than eight years old.

Even if you ignore the capabilities of the language, best practices change over time. Like PHP features, Nova uses practices that are no longer best (and may never have been). Take, for example, how Nova interacts with the database. Right now, Nova just calls the models directly within the controller. While that’s perfectly valid, it doesn’t make code very testable or interchangeable. If I wanted to start using a new system for database interaction, every controller would have to be updated. Not only is that a lot of work, but it requires a lot of testing to make sure nothing breaks. Instead, using a design pattern like the repository pattern means that the repository is what’s called in the controller and if I want to change the way Nova interacts with the database, I can just write a new implementation of the repository and bind that new implementation to the repository. Now, without changing a single line of code in the controllers, Nova is interacting with the database in a completely different way.

When you throw in the use of decoupled components, dependency managers, service providers, user interface toolkits, and tons of other design decisions (both visual and under the hood), it becomes really clear how major versions provide the opportunity to put the entire system together in a better way that utilize better practices, paradigms, and language features.

Moving Forward

It’s been almost 5 years since Nova 1 was released, and in that time, the Internet and development worlds have evolved at a breakneck pace. Nova has fallen severely behind the curve over that period, and while Nova NextGen won’t move it ahead of the curve, the goal is to be closer to the curve than it is now.

One of my responsibilities with Nova is to keep things as stable as possible, but at the same time, move things forward. There have been 3 minor updates to Nova since 2.0 and each of them have added features that enhance how people manage their games. Each release is a good step forward for the system. However, the goal with any minor release is to not rock the boat. Breaking backwards compatibility is a huge no-no with a minor release. Going from Nova 2.0 to 2.1 shouldn’t mean losing functionality or data. To avoid those types of situations, Nova adheres (albeit loosely) to semantic versioning, or the idea that version numbers convey meaning about what’s been changed. If it breaks backwards compatibility or changes the architecture, it requires a major version change. Minor versions should never introduce those kinds of changes. You can begin to see how that ties my hands with pushing the system forward. In order to really move Nova forward and make any progress, I’ve gotta break things.

Change can be painful. The move from SMS to Nova wasn’t the smoothest transition, but it was necessary. In the end, the product and community were better off because of it. Even moving from Nova 1 to Nova 2 wasn’t without its hiccups, but again, the architecture changes in Nova 2 made updating to newer versions a breeze. (Does anyone remember the updating process for SMS and Nova 1? Ugly.)

So yes, major versions are painful and annoying and frustrating, but they’re necessary, and once the dust settles, the next generation of Nova will provide a more powerful, more robust foundation to build and play your games on.

So let’s break some shit and make Nova better!