Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT

[jburwell]

Often, patch and security releases do not require schema migrations or
data migrations. However, if an empty upgrade class and associated
scripts are not defined, the upgrade process will break. With this
change, if a release does not have an upgrade, a noop DbUpgrade is added
to the upgrade path. This approach allows the upgrade to proceed and
for the database to properly reflect the installed version. This change
should make the release process simpler as RMs no longer need to
rememeber to create this boilerplate code when starting a new release.

Beginning with the 4.8.2.0 and 4.9.1.0 releases, the project will
formally adopt a four (4) position release number to properly accomodate
rekeases that contain only CVE fixes. The DatabaseUpgradeChecker and
Version classes made assumptions that they would always parse and
compare three (3) position version numbers. This change adds the
CloudStackVersion value object that supports both three (3) and four (4)
version numbers. It encapsulates version comparsion logic, as well as,
the rules to allow three (3) and four (4) to interoperate.

• Modifies DatabaseUpgradeChecker to handle derive an upgrade path for
  a version that was not explicitly specified. It determines the
  releases the first release before it with database migrations and uses
  that list as the basis for the list for version being calculated. A
  noop upgrade is then added to the list which causes no schema changes
  or data migrations, but will update the database to the version.
• Adds unit tests for the upgrade path calculation logic in
  DatabaseUpgradeChecker
• Removes dummy upgrade logic for the 4.8.2.0 introduced in previous
  versions of this patch
• Introduces the CloudStackVersion value object which parses and
  compares three (3) and four (4) position version numbers. This class
  is intended to replace com.cloud.maint.Version.
• Adds the junit-dataprovider dependency -- allowing test data to be
  concisely generated separately from the execution of a test case.
  Used extensively in the CloudStackVersionTest.

Signed-off-by: John Burwell meaux@cockamamy.net

/cc @rhtyd @karuturi

[yadvr]

LGTM
@blueorangutan package

[blueorangutan]

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[yadvr]

There seems to be build failure around db path or marvin, I can check this

[blueorangutan]

Packaging result: ✔centos6 ✔centos7 ✔debian repo: http://packages.shapeblue.com/cloudstack/pr/1654
Job ID-98

[yadvr]

I think a db upgrade path is missing causing Travis failures.

[yadvr]

@jburwell I've added an empty upgrade path. Tested the db upgrade locally. LGTM.
When you fwd-merge on 4.9 use: git merge -X ours 4.8 to avoid fixing merge conflicts in pom.xm files by hand. Merging 4.9 on master should not then cause any conflicts. We'll then also need to add/update db upgrade paths from 4.8.2 to 4.9.1/4.10.0 db versions (separately)?

[jburwell]

@rhtyd I have updated this PR to reflect version being 4.8.2**.0** rather than 4.8.2. I also added empty migration scripts to maintain consistency with previous releases (e.g. 4.8.1). Could you please test and verify?

@karuturi@abhinandanprateek@murali-reddy could you please provide a code review?

[jburwell]

@rhtyd The Travis build for this PR is failing with the following error:

========> Processing SQL file at /home/travis/build/apache/cloudstack/developer/target/db/templates.simulator.sql
Unable to execute /home/travis/build/apache/cloudstack/developer/target/db/templates.simulator.sql: Unknown column 'state' in 'field list'

A similar error is occurring on the builds for PR #1636.

[yadvr]

@jburwell changing code version (in pom.xml) to 4.8.2.0-SNAPSHOT is a valid change, but due to the way our db upgrade path works please revert the change on db upgrade path names and string values to 4.8.2 as explained for a similar change in #1665
The Travis failures were caused due to the change in db upgrade path names, they failed at the deploydb step.

[jburwell]

@rhtyd I have updated this patch to properly support four position version numbers, as well as, remove the requirement that all versions have a DbUpgrade class defined and/or an upgrade path. Please see the commit message for more information about the scope and reasoning for these changes.

[yadvr]

@jburwell I've fixed the issue failing db upgrade, it was a minor comparison issue in the beginning of the upgrade process. On my local env the upgrade worked as expected. LGTM.

[jburwell]

@syed per our conversation on Slack, the following is the test procedure to verify this PR:

1. Create a fresh install 4.8.1. Since we are verifying the database upgrade, the install only needs to start the Management Server.
2. Build this PR and deploy it against the 4.8.1 database
3. Restart the Management Server will trigger a database upgrade

Following database upgrade operation, the database version in the database should be 4.8.2.0.

/cc @rhtyd @karuturi

[yadvr]

Lgtm.

[abhinandanprateek]

Looks good on code review
here is my LGTM

[yadvr]

Given Travis has passed with 2 LGTMs and test LGTM, I'll go ahead and merge this after testing this across 4.8->4.9, 4.9->master.

[yadvr]

Tests on 4.8 branch, all pass:

- Clean db setup works, last upgraded version to 4.8.2.0.
| 18 | 4.8.2.0 | 2016-09-01 09:56:21 | Complete |
- Upgrade tests from 4.8.0.

[borisstoyanov]

LGTM, I've stated management and the DB got updated to 4.8.2

[yadvr]

Tests on 4.9 branch (after fwd-merge), all pass:

- Upgrade from 4.8.2.0 to 4.9.1.0
- Clean fresh db deployment

[yadvr]

Tests on master branch (after fwd-merge), all pass:

- Upgrade from 4.8.2.0, upgrade from 4.9.1.0
- Clean db deployment

[yadvr]

Based on the tests and review. I'll proceed with merging this and fwd-merge this across 4.9, master branches.

[syed]

@jburwell looks like @rhtyd already tested this. Do you need another testing? I am currently setting up my env

[jburwell]

@syed we received the LGTMs necessary overnight. Thank you for helping out.