Over the past year it may have been quiet on this blog, but we have not been sitting on our hands. We upgraded our web sites (more on that later, in another post) and in January we started upgrading our clients to Mytimetable 2.1. Recently, we upped the version number to 2.2. This post gives an overview of the changes and explains our versioning policy.
Changes in MyTimetable 2.1 and 2.2
For both MyTimetable 2.1 as well as 2.2, the focus has been very much on refactoring and polishing the existing code base. Because of this, many of the changes are not directly visible to our customers. Nevertheless, a couple of nice features have been added to MyTimetable. Our release notes discuss these features and can found on our documentation wiki. The direct links are:
While reading these release notes, please keep in mind that it is impossible to list every bug fix and change we make. The only change list that is 100% complete can be found on GitHub, where all of our customers have access to the full MyTimetable commit logs. If you do not yet have access to our GitHub environment and would like to access these logs, your issue tracker, and your source code, please drop us an email with your GitHub.com user name. More on our GitHub workflow will follow in an other post.
On the wiki you can even find a list of features planned for the upcoming MyTimetable version. But please remember that this list can change at any time.
MyTimetable versioning policy
Since our move to GitHub, we have adopted a stricter versioning model. Every version is represented by a branch in our source control system. Think of a branch as a parallel universe. This means that at any moment in time, we are developing and maintaining multiple versions of MyTimetable. Three to be more precise:
- Stable, currently 2.1: only critical bug fixes or bug fixes of which we are 99% sure they do not break anything else will enter this branch.
- Stabilizing, currently 2.2: our preferred MyTimetable version. We are confident this version is ready for production use, but since it contains more recent code and features than the stable branch, there probably are a couple of bugs hidden here and there (which we squash as soon as someone finds one). No new features will enter this branch.
- Development, currently 2.3: all new features and other enhancements enter this branch. On GitHub this branch is always referred to as master.
Bugfixes are regularly merged into the stabilizing and development branch, so the development branch always contains the latest and greatest code (and the most bugs). This is the code we work with when deploying to new customer sites; because that MyTimetable instance will generally not be used in production until all new features and change requests have been implemented it is the ideal place to test the latest code.
On top of this, every customer runs a unique MyTimetable version, with a unique configuration, styling and code base. Your major and minor version, as well as the specific Git changeset that your MyTimetable instance was built from, can be found in the MyTimetable Settings dialog on the Status tab, in the format:
If you have any questions regarding our versioning policy, please feel free to leave a comment below or drop us an email.