Indicate if there are security issues in the Release Notes

Hi devs,

It would be interesting for our users to know releases which have security issues since that makes it more compelling to them to upgrade. It also allows them to not upgrade if the new versions don’t have security issues fixed. See LTS updates with security issues

So here are 3 choices:

  1. Just indicate that the release contains security issues fixed
  2. Indicate the number of security issues fixed
  3. Indicate the number the number of high, medium and low security issues fixed

On my side, I’m fine with the 3 options. I think that 3) is acceptable.



I prefer 1.

-0 for 2 and 3.

Note that the reason I think 2 and 3 are not a problem is because anyone who wants to find and exploit security flaws in XWiki doesn’t need to look at the release notes: they just need to look at the commits and the source code. Thus I don’t think it matters that we mention the # of issues and severities in the release notes. Actually I think it does matter that we do as it’ll definitely help users to be motivated to upgrade if they know that, say, an important security flaw has been fixed in a given version.

1 Like

Reviving this proposal since we just had the need with 13.9 release.
I’m +1 for 1 and 2, -0 for 3 but mainly because it’s more work when releasing and I don’t think it’s such an important thing to indicate.

Now as @tmortagne mentioned on Matrix, we also need to decide if we display those info only in RN or also in the blog and forum posts when a release is done.
We also probably need to add that in the release note template, and add the related check in release plan.


+1 for 1 and 2
+0 for 3

+1 to display the information in the blog and forum posts.

I don’t think it’s more work (or really marginal) because we are already supposed to do the analysis and tag the security issues in jira accordingly. So it’d be just about copying that information.

Re the important part, I think it’s very different for a user to know if a release contains a critical security fix (it mean they MUST upgrade) from some low level security fix (they can wait to upgrade without problems).

In short 3) means putting the jira security tags visible in the RN.

Note: I still think that the main interesting point for our users are 3) ie. to know the severities and thus how important it is for them to upgrade. But we need to agree.

Once we start displaying more information about security fixes in the RN, our users will likely want to contact us to know more about the specific issues. So I think we need to anticipate this and add a paragraph in the RN linking to the Security Policy and link explicitly to the part mentioning when they’ll be made public.

+1 for 2.


What about indicating a) if security issues were fixed and b) the highest severity of the security issues fixed for the release? I don’t think the number of issues says much (there could many tiny issues or one very important one) but the highest severity might be interesting to know how urgent an update is.

A link to our security policy should also always be included to let users know what this severity means and to reference the disclosure policy.

I think that the conclusion so far is that we’re ok to do at least 1. But not everyone agrees about 2 or 3.


  • Vincent: 1, 2, 3
  • Thomas: 1
  • Simon: 1, 2
  • Manuel: 1, 2
  • Marius: 1, 2
  • Michael: 1, 4 (new proposal)

So WDYT about Michael’s proposal which is:

  1. Indicate if there are security issues fixed AND also indicate the highest severity of the security issues fixed for the release.


This is now effective, see for example

+1 from me for 4.


+1 for 4.



Since we agree, I’ve documented it in the RP template at

And in the RP help:

Now it’s not easy for the releaser to know the highest security value since that info is not available in the jira issues related to security. We only have labels. Do we also need to add a custom field in jira for the score?