Status Quo:

Currently, the values for ${BUILDS_ALL_TIME}, ${BUILDS_TODAY}, ${BUILDS_THIS_MONTH} and ${BUILDS_THIS_YEAR} will only increase by 1 for each new (successful) build. The only exception to this is explicitly overriding the next value by hand.

Problem:

For automated builds this is not practicable, because it requires way too much manual interaction / modification.

Sometimes it would be beneficial if another (upstream) build-job could provide a new number for one of these values or if it could be calculated outside of Jenkins and injected into the build-process.

Feature-Request:

A useful extension to the versionnumber plugin which solves this short-coming would be to extend the usage of the form-fields in the job-configuration (, which currently are only used to override - by hand - the next value with a number):

Instead of just taking a number which overrides the value for the next build, it should be possible to provide an environment-variable in this field. This environment-variable should then be checked during the next build and its value used as the corresponding number.
However, if during the next build that environment-variable is not set or its value is not convertible into an integer, the standard behavior should kick in as if the field would have been left blank. (This means, the corresponding value of the previous build should be taken and increased by 1, and that value should be used instead.)

Solution:

I already have implemented this extension and will provide a pull-request.
I hope others will find this extension useful so that it gets integrated.