Re: Review Request: Set correct version for database version check
On Wed, Sep 12, 2012 at 6:25 AM, David Nalley da...@gnsa.us wrote: I agree - there are also practical problems from a packaging perspecting. 4.0.0.5 is version 4.0.0.5 - but 4.0.0-5 is version 4.0.0 release 5. Plus we've agreed previously on a versioning strategy of n.y.z You have to be exceptionally careful here. 4.0.0-5 is only release 5 if you have voted on it. Perhaps you mean build 5? I am presuming that anything with a build number will never be voted on, and will never be in release? Is the versioning scheme documented anywhere? This came up on another thread, and I suggested Semantic Versioning, and someone chimed in with support of that. Thanks, -- NS
Re: Review Request: Set correct version for database version check
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7013/ --- (Updated Sept. 25, 2012, 2:27 p.m.) Review request for cloudstack. Changes --- What I really wanted to fix with this patch, is let us type just waf rpm and get a working binary. Leaving version number as 4.0 is problematic anyway. So I narrow the scope and submit a new patch. Description --- Reading com.cloud.maint.Version in server, version numbers must be x.x.x and artifacts should be appneded with -. This patch will fix startup database check errors in management server. Diffs (updated) - wscript ff38ed2 Diff: https://reviews.apache.org/r/7013/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: Set correct version for database version check
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7013/#review11906 --- Ship it! Ship It! - edison su On Sept. 25, 2012, 2:27 p.m., Hiroaki Kawai wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7013/ --- (Updated Sept. 25, 2012, 2:27 p.m.) Review request for cloudstack. Description --- Reading com.cloud.maint.Version in server, version numbers must be x.x.x and artifacts should be appneded with -. This patch will fix startup database check errors in management server. Diffs - wscript ff38ed2 Diff: https://reviews.apache.org/r/7013/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: Set correct version for database version check
On Tue, Sep 25, 2012 at 4:22 AM, Noah Slater nsla...@tumbolia.org wrote: On Wed, Sep 12, 2012 at 6:25 AM, David Nalley da...@gnsa.us wrote: I agree - there are also practical problems from a packaging perspecting. 4.0.0.5 is version 4.0.0.5 - but 4.0.0-5 is version 4.0.0 release 5. Plus we've agreed previously on a versioning strategy of n.y.z You have to be exceptionally careful here. 4.0.0-5 is only release 5 if you have voted on it. Perhaps you mean build 5? Sorry - terminology disconnect here. In packaging, 'release' is considered: The release tag can be thought of as the package's version. The release is traditionally an integer — for example, when a specific piece of software at a particular version is first packaged, the release should be 1. If it is necessary to repackage that software at the same version, the release should be incremented. When a new version of the software becomes available, the release should drop back to 1 when it is first packaged. See: [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html --David
Review Request: Set correct version for database version check
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7013/ --- Review request for cloudstack. Description --- Reading com.cloud.maint.Version in server, version numbers must be x.x.x and artifacts should be appneded with -. This patch will fix startup database check errors in management server. Diffs - wscript f1c9b62 wscript_configure dcea410 Diff: https://reviews.apache.org/r/7013/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: Set correct version for database version check
On Sept. 11, 2012, 6:06 p.m., edison su wrote:
We just need to fix the parameter passed into build system. Right now, the
version number 4.0.{build number} is passed in, so each time, from mgt
server point of view, it's a different version. We can change to
4.0.0.{build number}. I'll fix it in
http://jenkins.cloudstack.org/job/build-cloudstack-master-rhel6.3/configure,
change the package-version to 4.0.0, instead of 4.0
4.0.0.{buil number} works, but I prefer 4.0.0-{build number} in the MANIFEST.MF
because com.cloud.maint.Version#trimToPatch handles -.
To clarify, I would note that in current code, which passes 4.0.{build number},
does not work because management server will raise an exception at
com.cloud.upgrade.DatabaseUpgradeChecker#upgrade with a message There is no
upgrade path from 4.0 to 4.0.{build number}. The database version would be
upgraded to 4.0.0 by com.cloud.upgrade.dao.Upgrade302to40 , and that does not
match against 4.0.{build number} written in jar manifest Implementation-Version.
- Hiroaki
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7013/#review11343
---
On Sept. 11, 2012, 10:08 a.m., Hiroaki Kawai wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7013/
---
(Updated Sept. 11, 2012, 10:08 a.m.)
Review request for cloudstack.
Description
---
Reading com.cloud.maint.Version in server, version numbers must be x.x.x and
artifacts should be appneded with -. This patch will fix startup database
check errors in management server.
Diffs
-
wscript f1c9b62
wscript_configure dcea410
Diff: https://reviews.apache.org/r/7013/diff/
Testing
---
Thanks,
Hiroaki Kawai
