Release Drafter convention for 'do not use this release' or 'known issues'

[Chris Kilding]

Hi all,

While fixing a bug that I'd accidentally introduced in a previous release, I wondered whether we should have a convention in Release Drafter to indicate something like "known issues" or "do not use this release".

Some issues make a plugin release unusable, so users need to skip it outright. We have the system for unpublishing broken releases, but no convention for release notes so every plugin does its own thing. Example: https://github.com/jenkinsci/configuration-as-code-plugin/releases/tag/configuration-as-code-1.37

Other issues aren't showstoppers, but might benefit from being retrospectively added to the release notes under a "known issues" heading. I don't think we have any conventions for this.

Thoughts welcome.

Regards,

Chris

[Tim Jacomb]

Hi Chris

I'm not sure if it fits into release drafter, as it only updates drafts, as soon as you publish the release it won't be updated by the tool anymore.

I assume you would never publish a knowingly broken release and it would only be known retroactively.

What sort of convention are you thinking of? Just a recommendation of this is how you should communicate it to users? A line in documentation somewhere?

Thanks

Tim

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bb5f15a0-0923-49a1-be9d-27f3940aad8f%40www.fastmail.com.

[Gavin Mogan]

I believe there is also a file in update center that can be used to prevent a release from showing up anywhere.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidaa8iPAm-7cGdxFKY6vd8Prp4VfRUgqHWas%2BxWTNjNZQ%40mail.gmail.com.

[Chris Kilding]

Hi both,

Tim - yes this convention would be for issues that are only discovered after release.

As I see it there are two categories of issue we'd want to capture:

1. Do not use: The release has been unpublished (so you need to skip it)

2. Known issues: The release is not entirely broken and works for some users, but contains a showstopper for other users (so either use caution when upgrading, or skip it)

I wouldn't expect it to be used to note minor issues.

As you say there is probably no practical automation for this, although if we were feeling fancy for (1) maybe we could build something that scrapes the unpublished releases list and proposes edits to the release notes of those versions. But while Release Drafter can't do this itself, I was thinking of reserving a section name like "Known Issues" or "Do not use this release" (with corresponding emoji) and putting it in the release-drafter.yml config, to ensure that nothing else uses it.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duu0k2gPpFWP%2BP4gMRMvSNAbEHQDo1RXsZuyRtqFmwP_ag%40mail.gmail.com.

[Tim Jacomb]

That makes sense, you should be able to add it to the bottom commented out and a maintainer could then uncommonly as require.

Not sure how often this happens in practice though

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3ce4ae1f-c7ec-4991-8ee3-498168564184%40www.fastmail.com.

[Oleg Nenashev]

Release Drafter is not designed for adding post-release events, and so far we do not have a standard format recommended anywhere.  I would suggest using warning boxes on the top. E.g. 

| WARNING: Do not use this release. There is major regressions reported for it:  [JENKINS-12345](https://issues.jenkins-ci.org/browse/JENKINS-12345) |

| --- |

Release titles can be also updated to put a warning there.