Release management: security fixes need their own revision release

With all due respect to the developers and maintainers of Piwik, I want to put forward a point that I think is very important.

Piwik has been on a wonderful streak, with a number of releases following eachother in quick succession. We got new functionality, fixes and speed-ups. Great!

Releases 2.2.0, 2.4.0 and now 2.8.0 are rated critical because they offer a security fix. However, these releases do not only contain a security fix, but also additional changes and in the case of 2.8.0 also API changes. Because of the security fix, which by fixing it, is now out in the wild, end users are practically forced to upgrade.

I believe it is best practice to release security fixes separately and indicate the version by bumping the revision number. The security fixes mentioned before could have been released as versions 2.1.1, 2.3.1 and 2.7.1.

This allows end users to quickly and safely update and fix security issues, without having to rush a complete test and validation cycle on the application as a whole.

I think that releasing security fixes separately will make Piwik an even more awesome product, so I’d love to hear if this opinion is shared and whether there are any substantial downsides to this proposal. Thanks!

I agree with fschaap’s proposal. A brief 2.7.1 security release could have been installed quickly.
Piwik’s release cycle is quite fast-paced for me, and I usually wait some time before upgrading (high traffic site procedure). It seems that the release cycle is not even monthly, but 20-daysh.
Piwik is really great and I like it, but please balance the need for features with that of stability.

Thanks for your feedback! you make some good points.

We’ve changed our focus recently to focus on more bug fixing releases: 301 Moved Permanently

Also, it is our policy that we only support latest version of Piwik: How long is each release of Piwik maintained for? - Analytics Platform - Matomo

the issue with backporting security fixes is that it is very time consuming and our small team cannot afford time. Agility is key for Piwik to compete with the giants and this means kindly asking users to always upgrade to latest version (especially when rated critical - those ones that they are really critical)

So in general we will likely keep fast paced releases, but we will shift focus to more bug fixes rather than shipping many new features. Keep feedback coming!

Thank you for your reply matt!

Understood. Just as a side note, I usually run the latest stable, so this woudl have been shipping a 2.7.1 and postponing some days 2.8, non really what is usually meant by “backport”.

Enough with feedback, thank you and let me give a warm appreciation for the developers of Piwik!

I like the new 2.8.1 release :slight_smile:

Thanks for the reply Matt!

I understand the reasons and the choices made for the project at this time.

We are looking at integrating Piwik stats into our CMS interface in order to give editors a better understanding of how our site and content works. Without at least a stable API the effort appears more trouble than it’s worth. That’s a shame, because it would really enhance how we use Piwik and webstats for our organisation.

So, I still do think that at some point a stable branch is needed. I do understand why it’s not there at the moment, but I hope this request helps put it on the roadmap as a desirable “feature” for Piwik.

By stable API do you mean stable Reporting API and Tracking API? Those APIs are definitely stable and we don’t break them.
see: Tracking HTTP API: API Reference - Matomo Analytics (formerly Piwik Analytics) - Developer Docs - v3
Reporting API Reference: API Reference - Matomo Analytics (formerly Piwik Analytics) - Developer Docs - v3

When we change other APIs such as plugin APIs then we document here: Matomo Platform Changelog - Matomo Analytics (formerly Piwik Analytics) - Developer Docs - v3

Good point Matt!

I will discuss with our developer if we can only use the Reporting and Tracking APIs.