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 On Thu, 17 Sep 2020 at 14:12, Chris Kilding <[email protected]> wrote: > 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 > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/bb5f15a0-0923-49a1-be9d-27f3940aad8f%40www.fastmail.com > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidaa8iPAm-7cGdxFKY6vd8Prp4VfRUgqHWas%2BxWTNjNZQ%40mail.gmail.com.
