TLDR; This changes the way that version strings are parsed in the packaging to
make it easier for me to maintain topic branches/PPA builds. There should
be no changes to how things work today for standard Ubuntu kernels. But,
it allows for topic-branch maintainers to add an optional ".X" in the ABI
name, for reasons described below.

<Regression Testing>
------------------
Old Parsing:
  = abinum =
  $ echo "33.58" | sed -e 's/\..*//'
  33
  = uploadnum =
  $ echo "33.58" | sed -e 's/.*\.//'
  58
  = abi =
  $ echo "33.58" | gawk -F. '{print $1}'
  33

New Parsing:
  = abinum =
  $ echo "33.58" | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$/\1/'
  33
  = uploadnum =
  $ echo "33.58" | sed -r -e 's/[^\+]*\.([^\.]+(\+.*)?$$)/\1/'
  58
  = abi =
  $ echo "33.58" | sed -r -e 's/([^\+]*)\.[^\.]+(\+.*)?$/\1/'
  33
</Regression Testing>

When maintaining topic customizations that track Ubuntu kernel releases, it
is nice have the following features:

 1) Ability to decipher the base Ubuntu kernel revision used from the topic
    kernel's revision number
 2) Use a version that dpkg sorts > the base Ubuntu version
 3) Use a version that dpkg sorts < the next expected Ubuntu version
 4) Ability to retains the same ABI as the base Ubuntu version when the
    ABI has indeed not changed. This helps with e.g. d-i compatibility.
 5) Make use of ABI tracking facilities (vs. just disabling them)

This is difficult to do with the current version scheme, which encodes the
ABI number in the version string:

  <upstream-version>-<abi>.<rev>

I can tack a "+topic.<N>" to the end of rev, we can solve 1-3, but only as
long as as the ABI is the same. Once the ABI changes, I don't have a good way
to bump it. If I increment the ABI, we'll overlap with the next Ubuntu ABI
(breaking #4). If we jump to a huge ABI number (e.g. x100 to go from 32 to
3200), we'll have a package revision that will never again upgrade to an Ubuntu
version (breaking #3), and never get back to the Ubuntu ABI (again breaking #4).
I can of course use a linux-meta package to e.g. transition from a 3200 ABI back
to a 32 ABI at the packaging level, but the bootloader will still consider
3200 to be newer and therefore the default.

I've therefore started using the following scheme:

  <upstream-version>-<abi>(.topicabi)?.<rev>(+<topic>.<topicrev>)?

Where topicabi must always be >= <rev> (ugly, but necessary).

If I don't break the ABI, I can then branch and return like so:

3.16.0-8.6 -------------------------------------------------> 3.16.0-8.7
   \                                                             ^
    \                                                            |
     \--> 3.16.0-8.6+topic.1 -------> 3.16.0-8.6+topic.2 --------/

If I do need to break the ABI, I can branch and return like so:

3.16.0-8.6 -------------------------------------------------> 3.16.0-9.1
   \                                                             ^
    \       ABI break #1                   ABI break #2          |
     \--> 3.16.0-8.6.6+topic.1 -------> 3.16.0-8.7.6+topic.2 ----/
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>