This may not have the clearest of answers but how often do kirby updates contain fixes that can be considered as security related?
I am considering how often should a kirby site be updated, bare minimum.
Thank you
This may not have the clearest of answers but how often do kirby updates contain fixes that can be considered as security related?
I am considering how often should a kirby site be updated, bare minimum.
Thank you
That’s hard to tell, there are no regular security updates, only if security issues are reported/found. It is generelly advisable to update Kirby regularly, because we fix bugs and add new features.
If a Kirby release includes security-related fixes, we clearly point that out at the top of the changelog. So it’s best to keep an eye on the releases by using the “Releases only” watch feature on GitHub. Security releases are rare, but then you will notice them as early as possible. We also inform about security releases over all other channels (forum, Twitter, Slack).
But in general it’s as Sonja wrote: It’s always a good idea to keep Kirby updated. We are very careful with patch releases (i.e. 3.x.y) that there are no breaking-changes that will need changes in the code of the site or plugins. So you can always safely upgrade patch releases.
Thank you both.
On the other hand there were one or two minor usability changes or changes how a feature works, right? I think there should be a mention about the upcoming issue with stuff like this.
What do you mean?
This will be in a new major version (3.4), so there can be changes that affect how Kirby works. You will always find these in the changelogs (and the documentation). For example, if you scroll down in the changelog for 3.3.0, you will find a section “Breaking changes” and also “Deprecated methods” (i.e. methods you can continue to use for the time being, but you will get a notice if you do, so you can prepare for when they will no longer work).
The changelog should always be your go to when updating to a new version.
That’s right and that’s why I ask: I suspect the example given by @lukasbestle is a bit pitty. I think he means e. g. 3.4.x
, not 3.x.y
.
That’s the more general notation, because what @lukasbestle wrote, does not only refer to 3.4.x, but minor versions in general.
I’ve seen a bit of mixed naming here, so to ensure that we are on the same page: In Semantic Versioning, the naming is MAJOR.MINOR.PATCH
.
However we interpret it a bit differently as breaking-changes are much more common in large applications like Kirby (unlike libraries, which Semantic Versioning was designed for):
x.0.0
like 4.0.0
) are releases with major rewrites and/or large new features. For us it’s mostly about the license compatibility (a major release may need a new/upgraded license).x.y.0
like 3.4.0
) are feature releases that may contain clearly-documented breaking-changes.x.y.z
like 3.3.6
) are always safe to upgrade.