ActiveCollab 1.0 was released more than twelve years ago, and we have documented a detailed list of changes for almost all releases since then. Despite that heritage and experience, it has become tough to map a particular set of changes to a particular version in the past couple of months.
Our development and deployment process radically changed since we switched to Cloud and added more teams, and it is no longer “version number friendly.”
Don’t get us wrong - we are excited about each new release that we ship as much as we were in the past, and we want to share relevant details about them. What does require change is the format in which these updates are communicated.
What we changed
Instead of choosing between a full-blown blog post, or one-liners packed in release notes as we did in the past, we have started publishing monthly recaps. The first one was released in December. It covers improvements and changes that have been made to the product during November. With this format, we go into more detail about interesting changes, even when they are not “big enough” to get their own posts.
That does not help you a lot if you have a self-hosted version and get a release in the middle of the month, weeks after the previous recap. For that reason, as of December 2019, we’ll use a different release schedule for self-hosted releases. Each new release will be shipped right after the recap post, between the 5th and 10th of the month.
We’ll restrain ourselves from releasing new self-hosted builds in the middle of the month. If such releases do happen, there will be a strong reason for them, and they will be properly documented in the blog.
ActiveCollab Cloud accounts will keep on receiving updates as they did in the past - multiple times a day, with rollout schedules and plans tailored to stabilize deployed changes and user segmentation.
The previous paragraphs pretty much sum up the change of the release notes format. But feel free to continue reading if you are interested in learning more about our development and deployment process, as they influenced this decision greatly.
10+ Years of Release notes
Publishing detailed release notes has been an old tradition of ours. As a result, we have details on almost all releases ever published, and there were many of them. Did you know that we improved the Safari 2 compatibility in ActiveCollab 1.0.2? Or that the auto-upgrade feature was added in ActiveCollab 3.3.5? Guess when were column and timeline task views introduced! (to save you the trouble, it was in ActiveCollab 5.5).
ActiveCollab never had the official role of a Release Manager, but if there ever was one, I would have held it for the majority of the past 12+ years. When I put on a Release Manager “hat” and look back at these documents, I see two “eras”:
- The first was the time when we had only the self-hosted edition of the product, and
- The second is the period when the Cloud edition was the tip of the spear, with self-hosted lagging a bit behind.
There was no clean-cut between the two eras, but there is a visible shift between ActiveCollab 4 (when Cloud was introduced), and ActiveCollab 5. With version 4, the self-hosted edition was still dominant, and it controlled the scheduled release of the Cloud version as well. The releases were shipped with sequential version numbers, and an accompanying Cloud release followed the self-hosted release.
Cloud vs. Self-hosted
Release notes for version 5 show that in that period, Cloud began to lead the way. While way better than shipping software on DVD-s, providing a web application people need to download and install is hard. Changes had to be batched so that we wouldn’t bother people with frequent upgrades. The software is built for all sorts of environments and configurations, and support is much harder because of that.
Cloud gave us much-needed flexibility to get better at delivering software. It let us release upgrades more often and target features in a better way to different groups of users. If any software problems arise, we can correct them in a timely fashion, sometimes before anyone noticed any issues in the first place.
What was new about version 5 release notes is they started to skip versions. At that time, we started building and shipping releases at least once a week, and not always to all users. Our deploy system supports three release targets (we call them “release channels”):
- Edge - only our test accounts, including accounts we use to manage the ActiveCollab development,
- Beta - teams that agreed to test experimental features before their official release,
- Stable - everyone else.
The team used Edge and Beta release channels to integrate software more often and to see how things fit together in production. Once everything was tested and stable, we would push it to the Stable channel and provide release notes of the changes made since the last stable release. We kept doing this for a couple of years, and it has served us well.
New people - new process
Things started to change in 2018, as more people started working on the product, and our infrastructure evolved. Currently, we have four teams working on different aspects of the product and infrastructure and targeting different release channels. Our rollout system has evolved, so now changes made on one channel can be easily pushed to another release channel. Features can be selectively turned on to different groups of users, thanks to feature flagging.
All this makes pinning a particular change to a particular version number hard, almost detective work. If I had to draw it, I would draw pre-Cloud release schedule as a single line where changes get integrated and deployed linearly:
Our new process can be depicted like this:
The first process does look simpler, and it’s how many people envision software delivery, Roadmap as a straight line.
On the other hand, many teams are turning to different processes to be able to deliver more value and compete in the marketplace. The process needs to allow space for experimentation, incremental rollouts of features and tests, selective availability of functionalities by demography, account age or usage patterns, etc. Such a roadmap looks more like a map, with different nodes and turning points, and less like a tunnel.
That’s a wrap!
Hopefully, you found this information interesting and not too boring. The simple fact is we’re not running a train on rails. It feels more like trying to find the shortest route during rush-hour through a not-so-familiar city. There are jams, turns, and traffic lights, and you may end up taking a different route toward your destination based on a situation encountered while driving. The process needs to allow that, and ours naturally evolved in that direction.
The market is unforgiving, and our competitors are well funded, smart, and nimble. In such an environment, we need to get rid of practices that slow things down without providing substantial value and find smarter ways of working and delivering useful software.
A monthly release schedule for self-hosted builds and recap posts offer the necessary information to make an informed decision on whether to upgrade or not while letting us further adapt and evolve our processes. This way we’ll be able to build more useful software, faster.
