On Tue, Sep 11, 2012 at 7:50 PM, Hiroaki Kawai <ka...@stratosphere.co.jp> wrote: > > >> 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. >
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 --David