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

Reply via email to