<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">-1 for using timestamps first in
qualifier, I spent to much time figuring out why builds were
failing<br>
<br>
+1 to follow the rules<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
{quote}<br>
major.minor.micro.Alpha[n]<br>
major.minor.micro.Beta[n]<br>
major.minor.micro.CR[n]<br>
major.minor.micro.Final<br>
{quote}<br>
<br>
with modifications<br>
<br>
major.minor.micro.Alpha[n]-vYYYYMMDD-HHMM-Hnnn<br>
major.minor.micro.Beta[n]-vYYYYMMDD-HHMM-Hnnn<br>
major.minor.micro.CR[n]-vYYYYMMDD-HHMM-Hnnn<br>
major.minor.micro.Final-vYYYYMMDD-HHMM-Hnnn<br>
<br>
it means if we have a branch for Alpha1 and trunk is moved to
Alpha2, trunk build always has bigger versions and no more
problems with branch build is picked up from local/remote repo. <br>
with timestamp first it would pick up latest build no matter where
it is built from, that is unpredictable and takes time to figure
out why build is failing.<br>
<br>
Denis<br>
<br>
On 08/24/2012 11:05 AM, Nick Boldt wrote:<br>
</div>
<blockquote cite="mid:5037C263.7000103@redhat.com" type="cite">The
rules state we must end with .Final (and .GA for products):
<br>
<br>
<a class="moz-txt-link-freetext" href="https://community.jboss.org/wiki/JBossProjectVersioning">https://community.jboss.org/wiki/JBossProjectVersioning</a>
<br>
<br>
So... either we prefix with timestamps, or we prefix with an
alphabetic sequent culminating in .Final (and .GA for products).
<br>
<br>
IMHO, the best plan, if you insist on alias before timestamp, is:
<br>
<br>
* for nightlies & releases toward milestone/RC builds
<br>
<br>
I-M1-yyyymmdd-hhmm-B###
<br>
I-M2-yyyymmdd-hhmm-B###
<br>
S-Beta1-yyyymmdd-hhmm-B###
<br>
S-CR1-yyyymmdd-hhmm-B###
<br>
<br>
then
<br>
<br>
vyyyymmdd-hhmm-B###.Final (or vyyyymmdd-hhmm-B###.GA for product)
<br>
<br>
* for nightlies & releases toward maintenance builds
<br>
<br>
M-M1-yyyymmdd-hhmm-B###
<br>
S-CR1-yyyymmdd-hhmm-B###
<br>
<br>
then
<br>
<br>
vyyyymmdd-hhmm-B###.Final (or vyyyymmdd-hhmm-B###.GA for product)
<br>
<br>
(Note that I'm using B### intead of H${BUILD_NUMBER} because we
use Jenkins now so "*B*uild" makes more sense than "*H*udson" as
the prefix character.)
<br>
<br>
By using the I, M, S, and v convention, you ensure that:
<br>
<br>
* builds in the stream toward x.y.0 are always older than builds
in the stream toward x.y.1, because I < M... even if the
feature's base version hasn't changed.
<br>
<br>
* builds later in the cycle (Beta and CR) are always newer than
builds earlier in the cycle (Milestones), because a stable build S
> M > I.
<br>
<br>
* release builds are always newer than stables, milestones, or
maintenance builds, because v > S > M > I.
<br>
<br>
(Aside: if you don't like "v", we could also use "r", or any other
lowercase letter.)
<br>
<br>
N
<br>
<br>
On 08/24/2012 01:13 PM, Denis Golovin wrote:
<br>
<blockquote type="cite">
<br>
On 08/23/2012 08:26 PM, Max Rydahl Andersen wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">I did not say *remove* the date,
I said it should not be the significant decider for
p2.
<br>
<br>
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.
<br>
<br>
proper versioning that has semantic API meaning
instead of just rely on what date the build was made.
<br>
</blockquote>
In trunk it is now uses release type in front of the
date. It was fixed a month ago and works fine since.
<br>
I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds
and '${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}'
for hudson
<br>
</blockquote>
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
<br>
and bumping versions becomes that more important.
<br>
</blockquote>
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.
<br>
</blockquote>
okey - but M1 is higher than Beta1 afaics so this is not clean
as it stands.
<br>
<br>
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 ?
<br>
<br>
/max
<br>
<br>
</blockquote>
How about this sequence
<br>
<br>
M1,M2,M3,M4,RC1,RC2
<br>
<br>
where RC stands for Release Candidate. The only problem to solve
is pick
<br>
out build alias for Release.
<br>
<br>
R - would not work because it is less than "R-" < "RC"
<br>
<br>
Another options to pick up ( all works):
<br>
RL
<br>
RLS
<br>
REL
<br>
RELEASE
<br>
<br>
WDYT?
<br>
<br>
Denis
<br>
<br>
_______________________________________________
<br>
jbosstools-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>