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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bb5f15a0-0923-49a1-be9d-27f3940aad8f%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

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

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


On Thu, 17 Sep 2020 at 14:12, Chris Kilding <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidaa8iPAm-7cGdxFKY6vd8Prp4VfRUgqHWas%2BxWTNjNZQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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

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

On Thu., Sep. 17, 2020, 6:52 a.m. Tim Jacomb, <[hidden email]> wrote:
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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidaa8iPAm-7cGdxFKY6vd8Prp4VfRUgqHWas%2BxWTNjNZQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duu0k2gPpFWP%2BP4gMRMvSNAbEHQDo1RXsZuyRtqFmwP_ag%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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

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

On Thu, 17 Sep 2020, at 5:11 PM, 'Gavin Mogan' via Jenkins Developers wrote:
I believe there is also a file in update center that can be used to prevent a release from showing up anywhere.

On Thu., Sep. 17, 2020, 6:52 a.m. Tim Jacomb, <[hidden email]> wrote:
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 <[hidden email]> 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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3ce4ae1f-c7ec-4991-8ee3-498168564184%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

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

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

On Fri, 18 Sep 2020 at 11:36, Chris Kilding <[hidden email]> wrote:
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

On Thu, 17 Sep 2020, at 5:11 PM, 'Gavin Mogan' via Jenkins Developers wrote:
I believe there is also a file in update center that can be used to prevent a release from showing up anywhere.

On Thu., Sep. 17, 2020, 6:52 a.m. Tim Jacomb, <[hidden email]> wrote:
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 <[hidden email]> 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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].









--


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 [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3ce4ae1f-c7ec-4991-8ee3-498168564184%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifaAws840Qj8dpV-snPQnxHj%3DfrrQke_WpgRXRGc-nKYA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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

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.
On Friday, September 18, 2020 at 2:17:45 PM UTC+2 [hidden email] wrote:
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

On Fri, 18 Sep 2020 at 11:36, Chris Kilding <[hidden email]> wrote:
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

On Thu, 17 Sep 2020, at 5:11 PM, 'Gavin Mogan' via Jenkins Developers wrote:
I believe there is also a file in update center that can be used to prevent a release from showing up anywhere.

On Thu., Sep. 17, 2020, 6:52 a.m. Tim Jacomb, <[hidden email]> wrote:
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 <[hidden email]> 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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].









--


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 [hidden email].


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7dd1f54e-9737-4331-aa3f-89a784faddfbn%40googlegroups.com.