{"push_id":1278051215,"size":2,"distinct_size":0,"ref":"refs/heads/4.8","head":"f4ae87cb05b4ec0dfc0e63820b4090a1ba583f85","before":"19f159a96b0a565f1a70cdd745a6f2ca0c35207c","commits":[{"sha":"8d11511b1f2ac20b51c8f3f5290139a19a654672","author":{"name":"John Burwell","email":"233c2d87923d4495dd00eed2611de964eb2b6725@cockamamy.net"},"message":"Adds support for four position versions and optional db upgrades\n\nOften, patch and security releases do not require schema migrations or\ndata migrations.  However, if an empty upgrade class and associated\nscripts are not defined, the upgrade process will break.  With this\nchange, if a release does not have an upgrade, a noop DbUpgrade is added\nto the upgrade path.  This approach allows the upgrade to proceed and\nfor the database to properly reflect the installed version.  This change\nshould make the release process simpler as RMs no longer need to\nrememeber to create this boilerplate code when starting a new release.\n\nBeginning with the 4.8.2.0 and 4.9.1.0 releases, the project will\nformally adopt a four (4) position release number to properly accomodate\nrekeases that contain only CVE fixes.  The DatabaseUpgradeChecker and\nVersion classes made assumptions that they would always parse and\ncompare three (3) position version numbers.  This change adds the\nCloudStackVersion value object that supports both three (3) and four (4)\nversion numbers.   It encapsulates version comparsion logic, as well as,\nthe rules to allow three (3) and four (4) to interoperate.\n\n  * Modifies DatabaseUpgradeChecker to handle derive an upgrade path for\n  a version that was not explicitly specified.  It determines the\n  releases the first release before it with database migrations and uses\n  that list as the basis for the list for version being calculated.  A\n  noop upgrade is then added to the list which causes no schema changes\n  or data migrations, but will update the database to the version.\n  * Adds unit tests for the upgrade path calculation logic in\n  DatabaseUpgradeChecker\n  * Removes dummy upgrade logic for the 4.8.2.0 introduced in previous\n  versions of this patch\n  * Introduces the CloudStackVersion value object which parses and\n  compares three (3) and four (4) position version numbers.  This class\n  is intended to replace com.cloud.maint.Version.\n  * Adds the junit-dataprovider dependency -- allowing test data to be\n  concisely generated separately from the execution of a test case.\n  Used extensively in the CloudStackVersionTest.\n\nSigned-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>","distinct":false,"url":"https://api.github.com/repos/apache/cloudstack/commits/8d11511b1f2ac20b51c8f3f5290139a19a654672"},{"sha":"f4ae87cb05b4ec0dfc0e63820b4090a1ba583f85","author":{"name":"Rohit Yadav","email":"cd6636b2ef1583580b17d24fee28f0de526c38ee@shapeblue.com"},"message":"Merge pull request #1654 from shapeblue/jsb/4.8.2.0-version\n\nUpdating pom.xml version numbers for release 4.8.2.0-SNAPSHOTOften, patch and security releases do not require schema migrations or\ndata migrations.  However, if an empty upgrade class and associated\nscripts are not defined, the upgrade process will break.  With this\nchange, if a release does not have an upgrade, a noop DbUpgrade is added\nto the upgrade path.  This approach allows the upgrade to proceed and\nfor the database to properly reflect the installed version.  This change\nshould make the release process simpler as RMs no longer need to\nrememeber to create this boilerplate code when starting a new release.\n\nBeginning with the 4.8.2.0 and 4.9.1.0 releases, the project will\nformally adopt a four (4) position release number to properly accomodate\nrekeases that contain only CVE fixes.  The DatabaseUpgradeChecker and\nVersion classes made assumptions that they would always parse and\ncompare three (3) position version numbers.  This change adds the\nCloudStackVersion value object that supports both three (3) and four (4)\nversion numbers.   It encapsulates version comparsion logic, as well as,\nthe rules to allow three (3) and four (4) to interoperate.\n\n  * Modifies DatabaseUpgradeChecker to handle derive an upgrade path for\n  a version that was not explicitly specified.  It determines the\n  releases the first release before it with database migrations and uses\n  that list as the basis for the list for version being calculated.  A\n  noop upgrade is then added to the list which causes no schema changes\n  or data migrations, but will update the database to the version.\n  * Adds unit tests for the upgrade path calculation logic in\n  DatabaseUpgradeChecker\n  * Removes dummy upgrade logic for the 4.8.2.0 introduced in previous\n  versions of this patch\n  * Introduces the CloudStackVersion value object which parses and\n  compares three (3) and four (4) position version numbers.  This class\n  is intended to replace com.cloud.maint.Version.\n  * Adds the junit-dataprovider dependency -- allowing test data to be\n  concisely generated separately from the execution of a test case.\n  Used extensively in the CloudStackVersionTest.\n\nSigned-off-by: John Burwell <meaux@cockamamy.net>\n\n/cc @rhtyd @karuturi\n\n* pr/1654:\n  Adds support for four position versions and optional db upgrades\n\nSigned-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>","distinct":false,"url":"https://api.github.com/repos/apache/cloudstack/commits/f4ae87cb05b4ec0dfc0e63820b4090a1ba583f85"}]}
{"actor":{"display_login":"asfgit"}}