I wonder if it would be better if nixpkgs tracked Jenkins LTS releases. Currently we're tracking the weekly releases in both NixOS master and release-17.09, and it feels like a bit too much (IMHO). LTS releases get major updates every 12 weeks, followed by bug and security fixes.

https://jenkins.io/download/

Thoughs?

I'm fine with that, although I would want to make sure that LTS updates include all the latest security patches, which come frequently.

Is there anything bad about frequent updates to the Jenkins derivation, other than it feels noisy and costs PR review time?

Yes, LTS is supposed to get security fixes.

I get the feeling that the weekly updates also introduce bugs and security issues. (Just skimming through the changelogs.)

@bjornfor See #34962 for switching to LTS.

A good solution to this issue is one where the last 50 releases of Jenkins can be installed via a binary method and every git version could be built from source by simply passing an optional parameter to the package. Since new versions come out each week, the only way to support this is if some daemon would push updates to the Jenkins expression automatically to nixpkgs.

Jenkins upstream cannot be trusted to consistently produce versions that are usable in production.

Once that infrastructure is in place, we can do automated upgrades of Jenkins that don't require any human in the loop anymore.

The current approach in which a single version is sanctioned as being the best for every user of Jenkins does not match real world operations.

This PR is just a symptom of not having enough options. Instead of removing an option (the last weekly release), please do PRs which add options and expand capabilities.

every git version could be built from source by simply passing an optional parameter to the package

As a start, I think this should be doable via a combination of #30588 and a package override.