While we introduced some of our basic plans for 4.0 many months ago, we wanted to touch base again on some of these plans and expand upon some of our motivations behind decisions we have or will make for our upcoming 4.0 software release.
Before we get too far, let me just state now that there is no expected (or even estimated) release date for 4.0 yet. While we always have internal guidelines, timeframes and milestones, we do not communicate these publicly until we are absolutely sure they are as accurate as possible. The 4.0 Suite will be a major overhaul, effectively a rewrite of most areas from the ground up, and there are many factors that can affect delivering within expected due dates.
You may also have noticed the title of this blog entry uses a term for the suite you may not have seen used previously. We have decided to name the 4.0 Suite (which we will often refer to as "4.0 Suite" or "Social Suite", informally), officially as the IPS Social Suite. We feel that as we expand our line up and remove community-related dependencies, it is important that our main product release reflect the fact that our software can power more than just traditional communities.
Formalities out of the way now, here are a few of our driving motivations behind 4.0...
Modernize the interface
The skin delivered for 3.0 and again for 3.2 was great, but several years have since passed. It is time we modernize the user interface in our software lineup once again. Features have been added, trends on the web have shifted, and technologies have advanced. Some specific points you may be interested to know:
- All areas of the suite will support the mobile interface.
- We are heavily investigating using a "response design" for 4.0.
- We will be switching to jQuery
- We will be embracing HTML 5 fully
Modernize the underlying codebase
While 4.0 will not technically be a "complete rewrite", most of the underlying codebase will be rewritten in some manner, and all of the code will at least be updated to work within the new framework we are developing. There is a lot to go over for those of you who may be interested in the developer side of things, and I'll point you to the right place later in this entry, but as a general outline here are some things you can expect to see:
- PHP 5.3 will be the minimum supported version of PHP
- MySQL 5.0.3 will be the minimum supported version of MySQL
- IP.Board will fully utilize namespaces in PHP
- The entire directory structure, class naming structure and more will be completely overhauled
- The entire code base will be modernized. More use of formal design patterns will be employed, where appropriate. Dumping ground classes (such as IPSLib) will be avoided at all costs. More consistency between how applications implement functionality will be seen. Naming conventions will be more consistent.
- The way hooks work will be completely rewritten, making things simpler for us and for developers, and making hook usage behind the scenes more reliable (no more loadLibrary calls - everything is handled automatically by the framework instead).
Make things more consistent
We are also working towards making all of our applications more consistent. The approach to this actually has much more to do with planning and how we approach new functionality than it does any specific technical aspect of software development. In a nutshell, we will have one "suite" release moving forward starting at 4.0. Every application will be on the same versioning system and share the same version number, and every release will include every application (although you will only have access to the applications you have purchased, of course). What we will do as we implement new features is implement new functionality suite-wide from the start. If we were to add a new feature to 4.0, we would not add the functionality to the forums and then roll this change out to other applications as they see updates. Instead, we will be implementing changes suite-wide from the start, which has several benefits:
- From a user standpoint, the software will be more consistent. You won't have situations where a feature is available in Application X but not in Application Y.
- From a technological standpoint, we will be forced to implement functionality in an optimal manner where it can be utilized by all areas of the suite. There will be less application-dependencies for features that are intended to be suite-wide. There will be much, much less duplicated code as features will be designed from the start to work in multiple areas.
- Point #2 above will also benefit modders - APIs will be much more robust, yet more generic and reusable, for features implemented suite-wide rather than features implemented for one application and then shared across others.
Beyond changing our approach to functional changes in the software itself, we will also be focusing on consistency while redesigning the interface, and throughout every facet of development of 4.0.
Want to hear more specifics?
We have recently launched our new development blog where we will routinely be posting about the nitty-gritty of our day to day development duties here at IPS. While this blog is not at all intended to be specific to the development of 4.0, you will find us posting about upcoming changes and decisions made in 4.0 quite regularly. We welcome you to follow The Development Channel blog if you are interested in reading about these changes. If not, don't worry - any major announcements will be blogged about here in our company blog as well in due course.
If you aren't sure, just to be clear....development of 4.0 is definitely underway. A lot of planning and discussion took place prior to ever writing a single line of code for 4.0, however we are definitely working on 4.0 now and you will likely see blog entries about upcoming changes before long. Stay tuned!