Nice!
On Wed 19 Jul 2017 at 16:52, Daniel Beck <[email protected]> wrote: > Hi everyone, > > A question that comes up regularly: "What version of core should I depend > on in a plugin?". Maybe you don't want to arbitrarily limit who can use > your plugin, but want newer core features? This becomes more difficult > when your plugin has been around for a while, as now you have users that > may still be on older Jenkins releases. > > While we have some general guidelines in the wiki, we also have data that > can help understand usage patterns. The data discussed below has always > been available on the stats site, it just wasn't very accessible. > > So I added additional output to the stats generator that can be used to > inform decisions where to take core dependencies for existing plugins: > Every plugin that has usage stats now also has a file like the following > with a giant table in it (just replace the plugin ID in the URL): > > http://stats.jenkins.io/pluginversions/workflow-job.html > > This table shows which release of a plugin is installed how often on which > core release. The rows are Jenkins releases, the columns are plugin > releases (with the last column being the number of plugin installs for any > release on that core), and the values are number of installations. > Tooltips for each cell show what percentage of users are on any given core > or later for the current plugin release (or, in the 'Sum' column, any > plugin release). > > In this example (Pipeline: Job plugin), plugin releases 2.0 - 2.11.1 > required only core 1.642.3. How useful is such a low core release, as of > June? Version 2.10 has been around since February, plenty of time to > update -- and 90% of users on plugin version 2.10 are on Jenkins 2.32.1 or > newer. This seems to indicate that users on older cores generally don't > seem to care a lot about keeping their plugins updated. > > Some limitations: > - The numbers are off a bit compared to what you may be used to, as this > doesn't count releases like alpha/beta to keep the size of the table > manageable. > - Additionally, there's some weirdness going on with instances reporting > different core versions over time, so a handful of instances with > incompatible core releases may show up as using a given plugin release; I > expect that's not actually the case. > - It's still not easy to read the giant table for e.g. Git plugin, but > it's a start. > > Copying & pasting the page content from the browser allows transferring > the data into a spreadsheet with no further conversion, so you can perform > your own analysis pretty easily. > > The sources for this are in > https://github.com/jenkins-infra/infra-statistics -- it's basically all > JavaScript in > https://github.com/jenkins-infra/infra-statistics/blob/master/generateVersionDistribution-template.html, > so easy to iterate on if you want to improve the output format. > > Note that there's no directory index at > https://stats.jenkins.io/pluginversions/ (yet) -- my plan is to add links > to plugins.jenkins.io and make that the default entry point. > > I hope someone finds this useful. > > Daniel > > -- > 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/12163123-1269-45C0-B91E-116053E920C5%40beckweb.net > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- 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/CA%2BnPnMxpLQZMC0L9ZS2JKK4eZRP67_QK_Nx3Q%2BXQavvr-cWqJw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
