On 08/23/2012 08:26 PM, Max Rydahl Andersen wrote:
>>>> I did not say *remove* the date, I said it should not
be the significant decider for p2.
>>>>
>>>> i.e. Release of a version should make any nightly/snapshot builds of that
version invalid; today it does not because the data comes *before* the release type flag.
>>>>
>>>> proper versioning that has semantic API meaning instead of just rely on
what date the build was made.
>>> In trunk it is now uses release type in front of the date. It was fixed a
month ago and works fine since.
>>> I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds and
'${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}' for hudson
>> Oh - nice; that is news to me! Didn't see any notification on this ?
Shouldn't we get that out since this changes things for QE/testers/bleeding edge
installs
>> and bumping versions becomes that more important.
> We probably should, but I believe it is fine, because changed components should bump
the version and it means bumped version in X.X.X.M1_vXXXXXXXX-XXXX-HXXX format should be
higher than version in old format X.X.X.vXXXXXXXX-XXXX-HXXX-M1.
okey - but M1 is higher than Beta1 afaics so this is not clean as it stands.
Do we need to move to use Alpha's instead ? .... not too fond of that because
milestone is more neutral but don't see many other options ?
/max
How about this sequence
M1,M2,M3,M4,RC1,RC2
where RC stands for Release Candidate. The only problem to solve is pick
out build alias for Release.
R - would not work because it is less than "R-" < "RC"
Another options to pick up ( all works):
RL
RLS
REL
RELEASE
WDYT?
Denis