I should have known better than reusing the version number. Apparently
the issue isn't just in Maven.

Stack trace:

org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService
  at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
  at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
  at jenkins.model.Jenkins.executeReactor(Jenkins.java:885)
  at jenkins.model.Jenkins.<init>(Jenkins.java:790)
  at hudson.model.Hudson.<init>(Hudson.java:81)
  at hudson.model.Hudson.<init>(Hudson.java:77)
  at hudson.WebAppMain$2.run(WebAppMain.java:217)
Caused by: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService
  at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.<init>(LDAPSecurityRealm.java:419)
  at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:369)
  at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398)
  at hudson.security.HudsonFilter.reset(HudsonFilter.java:134)
  at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960)
  at jenkins.model.Jenkins$17.run(Jenkins.java:2524)
  at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
  at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
  at jenkins.model.Jenkins$7.runTask(Jenkins.java:874)
  at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
  at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  at java.lang.Thread.run(Thread.java:680)

When managing instances with lots of jobs, the size of the view
configuration screen becomes huge because there is one line per job on
the instance.

Going beyond this requires CSS animation.

... since they didn't go to RC.

Previously, the presence of the xpath parameter suppressed the tree
parameter processing. This change fixes that so that the tree parameter
can be used for building small DOM, then XPath to manipulate the data
further.

Added test whether the currently checked slave computer actually can take the buildable item before flagging it as needed (avoids powering up and connecting to slaves for jobs they can't build).

It uses Diffie Hellman to come up with one-time session key, then have
the server sign this session key to allow the client to verify that
there's no man in the middle.

Until now, Jenkins.overallNodeProvisioner was tracking an inconsistent
pair of numbers. On one hand, it was tracking all the executors in the
system, but then it was also only tracking the # of free-roaming
label-unassigned jobs as the queue length.

So if all your slaves are set with Node.Mode.EXCLUSIVE and you have some
free-roaming jobs, then it'll never tickle NodePrivisioner.

In other words, the # of executors weren't reflecting the actual # of
executors that can execute what's counted as the queue length.

See the problem report at
https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-dev/bUwGEgOwv4Q

To fix this, I introduced another LoadStatistics that only counts
the # of executors that can execute free-roaming jobs, and # of
free-roaming jobs as the queue length. In this way, two pairs of numbers
are consistent.

This now allows us to use overallLoadStatistics for really the entire
system, including all executors and the total queue length. This is
primarily for administrators to see the resource utilization, and it is
not useful for NodeProvisioner input because it's mixing too many
different things.

The semantics change in OverallLoadStatistics.queueLength allows us to
deprecate its totalQueueLength field.

Fall back in non-JNA case wasn't working.

Backward compatibility is preventing the View.READ permission to apply
correctly. It actually overrides the View.READ instead of complementing
it.

This change only applies default READ right if the View.READ is not
available, and the user has View.CONFIGURE + the view is not empty.

Include the file system path that was checked in the low disk space
error message

The actual fix was in c86aa679

The previous implementation was always appending the per-configuration unique suffix, making it impossible for different configuration builds to share workspaces. In this fix, we introduce a secondary field to control the workspace of sub-builds (which can be either absolute or relative to the matrix head workspace.)