Docker page - provide the content source for Releases info

[vsilverman]

Empty content for docker-plugin Releases

[zbynek]

This can be either fixed by Docker plugin switching to GitHub releases (@pjdarton looped) or plugin site implementing
#263 to grab the info from changelog. Maybe we should close this issue in favor of #263 .

[pjdarton]

GitHub releases are something I've heard of ... but know nothing about (other than the years-old bug where GH can't distinguish between releases and tags).
I'm quite happy to switch to GH releases, if someone can ensure my ignorance is no longer a barrier ;-)

... and given that a recent Jenkins release removed agent.jar's support for the -slaveLog argument, I'm going to have to do a new release fairly soon (next week maybe as I'm not working this week) so "now" would be a good time to do that switch.

[halkeye]

My suggestion is to use release drafter:

https://github.com/jenkinsci/archetypes/blob/master/common-files/.github/release-drafter.yml
https://github.com/jenkinsci/archetypes/blob/master/common-files/.github/workflows/release-drafter.yml

Then any PR you merge will get appended to draft release. and if you label the PRs, you'll get categories too.

With out that, you can create a new release and fill in fields, or edit a tag and publish as a release (so you can backfill as necessary).

[halkeye]

In sync with what? Docker? The plugins don't have docker releases.

[vsilverman]

Oh, yes, exactly right, mixed up Jenkins docker-plugin with Jenkins docker release. Those issues are unrelated, will remove my comment

[pjdarton]

So, from my point of view, while I generally approve of "automating everything", I think that XKCD is bang on the money here and one should take a more balanced view.
It doesn't take me long to update the CHANGELOG.md file, whereas the time taken to fully learn all the ins and outs of an automated process (especially the time taken to backfill old releases) would take me a lot of time that I don't have to spare.

If I was starting a brand new plugin so there was "nothing to lose", or if I was kicking out releases for things on a daily basis then, sure, it'd be worthwhile mastering that automated thing to save me some time, but I don't see the benefit right now - sometimes a low-tech option is best ("keep it simple") and I think this is one of those times.
(If I was working with Jenkins experts on a daily basis and able to lean over a desk-partition to ask "Oi! How does this bit work?" 10 times a day, then it'd probably be different, but as-is the cost of learning new stuff is non-trivial)

...so I would, instead, advocate having the plugin site being more flexible in where it gets its data from, e.g. #263 as that'll fix the issue for far more than just the docker-plugin.

[halkeye]

so I would, instead, advocate having the plugin site being more flexible in where it gets its data from, e.g. #263 as that'll fix the issue for far more than just the docker-plugin.

Nobody is stopping you from using it. Its just not implemented yet. Releases is easy you hit and endpoint then render it. Changelog is more complicated. There's no standard format so it'll require parsing and such. Just needs volunteer hours to implement

[zbynek]

@pjdarton you can also manually update the releases; in https://github.com/jenkinsci/docker-plugin/releases click the "draft new release" button and type in the same markdown you would type into changelog.

Also no need to move the old changelog, a simple note like the one in https://github.com/jenkinsci/git-plugin/blob/master/CHANGELOG.adoc should be enough.

[halkeye]

So all plugins will now have releases populated by update center. Release notes are still pending. But no longer be blank

[halkeye]

Actually this is a dupe of #263 now so closing it