Upcoming Major Version Release Strategy

The remnants of 'old school' Exponent are numbered...meaning very soon we'll no longer be strapped to the modules, subsystems, etc... of Exponent 0.9x that were necessary to get Exponent 2.0 up and flying. For the most part, we've been able to disguise the great differences between the 0.9x coding architecture and the 2.x MVC coding architecture. This was done by updating some of the old school (0.9x) module admin interfaces to look (and act?) similar to the 2.x modules. However this was done at some (resource) cost, and the complexity of having to deal with two different animals. Therefore we'll modify our release and development strategies to best accommodate existing installations, yet not restrict such a bold move into the future! What follows are some notes to Administrators/Designers and another set to Developers about how this will occur.

For Administrators/Designers - Putting out less-than-stable code for the upgrade of a production server is NOT what any administrator or user would expect, nor want to hear. However, moving to a fully updated 2.0 system (no old school code) would likely temporarily disable some sites, and may diminish the stability of a running site. That is, until some custom features (like a theme?) are upgraded on that site. So how can we maintain stability (a stable code release line), yet vastly change the way things work (implement a major change without stagnating the release flow)? By moving to a parallel release/development strategy!

What this means, is that while there will be many bug fixes and feature additions found in the next release (v2.1.1), it really won't be different from many of the releases over this past year (though looking back, some of the releases since 2.0.0 stable could be considered to have required major changes). And you can likely expect at least one more (late spring?) release in like manner (v2.1.2), but it may likely be the last of the 2.0/2.1 line. However, even that will NOT be a dead end, because it will be an easy move into the 'next' version (v2.2). Version 2.2 will leave 0.9x (old school) compatibility behind, but will continue to be backwards compatible with any v2.x themes, modules, etc... So things like any lingering old school modules (the ones found in the /framework/modules-1/ folder) or calls the old school theme compatibility layer (exponent_theme_xxx) will simply NOT exist (meaning the page will probably crash/break)! However, things like YUI2/YUI3 (javascript/styling library) will still be fully available, but begin moving into a background role. What will take front, center stage will be a reliance on 'Twitter Bootstrap' (styling library) and 'jQuery' (javascript library)! We may also leave PHP v5.2.x compatibility behind since v5.5.x is about to be released and the use of v5.3 itself is no longer recommended. The biggest change found in v2.2 will be a moderate change to the database which will prevent regressing to an earlier version (except by using an EQL backup)! In fact, installing the v2.2 code on an existing site will give you the impression the site was wiped out...until you run and complete the 'upgrade/install' process! So the big question is how can we move from a fully stable v2.1.2 to a fully stable v2.2?

Well the answer is to have both a stable release line (v2.1.x) and an unstable pre-release line (v2.2.x) running simultaneously. In some respects, we already do this with the stable release ('master' branch of the git code repo) and the working development code ('develop' branch of the git code repo). The BIG departure will be that unlike the 'develop' branch which is updated moment by moment and may be broken at times, the 'unstable' release will only be created as needed and should be a working set of code. Therefore, when you see v2.1.1 hit the street in the near future, you can expect the release of v2.2.0-alpha1 almost simultaneously. Any changes made to the v2.1.x line will also appear in the v2.2.x code, so if there are any future updates to the v2.0/2.1 line, it'll already be in the v2.2 code. Then once v2.2 becomes stable, the v2.0/2.1 line would only receive critical patch updates, with the intent being a move to the v2.2 line.

This strategy should allow for the stability needed by most production sites, and yet allow (early) access to new features in a somewhat less than 'bleeding edge' manner. For all intents and purposes, v2.2.0-alpha1 should be fully functional, but will NOT have been tested under many scenarios.

For Developers - Most of the changes will affect how we develop and release software updates, but primarily how we manage code branches. Though these won't be much different from how we've been managing code using the Git-Flow paradigm. For the most part, 'master' will (always) still be the most recent stable release. 'Develop' will still be the primary place for code updates to the stable release...in this case prep for a possible v2.1.2, but NOT the move to Twitter-Bootstrap, nor the Container 2.0 changes.

The big change however, will be the creation of several new branches of code in the git repo. There is already a new branch called 'feature/container2' which will become v2.2.0-alpha1. It already holds container 2.0, Twitter-Bootstrap, and a new bootstraptheme. These are the major changes slated for v2.2.0. The 'feature/container2' branch will be updated (merged) from the 'develop' branch on a regular (daily?) basis. Conversely, the 'develop' branch will NOT be updated from 'feature/container2' until just prior to the release of v2.2.0 (stable). We may also create a new 'hotfix' branch based on master AFTER the release of v2.1.1. It will be where any fixes for v2.1.1 would be coded and will be merged/updated into 'develop' (which in turn is merged/updated into 'feature/container2'). We will also create an 'unstable' branch as a substitute for pulling from the the repo using a tag like v2.2.0-alpha1. And as always there will be temporary (release testing) branches created between a code freeze and code release, which also includes any alpha and beta releases. Therefore, there will be several branches of code in the Exponent git repo:

master = most recent stable release (currently v2.1.0)

develop = changes/updates slated for the next stable release (currently v2.1.1 pre-release). It will hold any changes planned/needed for the v2.1 (2.0) line.

feature/container2 = work on the next major release v2.2.0, updated from 'develop' regularly. Will exist until AFTER v2.2.0 stable is released. At that point, 'master' would then hold v2.2.0 stable (the most recent stable release at that time), and all code work would move to the 'develop' branch. This branch can be thought of as the develop branch for v2.2.0 until it is stable.

hotfix = fixes need for the most recent stable release. Any work here wil1 eventually becomes a patch release to the current stable release. 'develop' is updated from this temporary branch. We will automatically create a 'hotfix' branch once v2.1.1 is released to hold any fixes that need to be applied to v2.1.1.

unstable = snapshot of 'feature/container2' at time of most recent unstable release, which is a substitute for pulling from the repo using a tag like 'v2.2.0-alpha1' or 'v2.2.0-beta1' This makes it easier to update/test on a site using git pull instead of the unstable package release.

So, if you want the most recent stable release, you'd pull from the master branch. If you want the most recent unstable release (alpha, beta, release candidate, etc...), you'd pull from the 'unstable' branch. If you want the pre-release of the next stable version, you'd pull from the 'develop' branch. And if you want the bleeding edge code, you'd pull from the 'feature/container2' branch.

For the most part this is a tried and true approach. It only seems new, because we didn't have a stable branch to deal with when we were working toward the first stable release of v2.0.0 . Most likely things will work there way back to how we operate now once v.2.2.0 is released as stable.