Re: [jbosstools-dev] change to have build_alias in front
The rules state we must end with .Final (and .GA for products):
https://community.jboss.org/wiki/JBossProjectVersioning
So... either we prefix with timestamps, or we prefix with an alphabetic
sequent culminating in .Final (and .GA for products).
IMHO, the best plan, if you insist on alias before timestamp, is:
* for nightlies & releases toward milestone/RC builds
I-M1-yyyymmdd-hhmm-B###
I-M2-yyyymmdd-hhmm-B###
S-Beta1-yyyymmdd-hhmm-B###
S-CR1-yyyymmdd-hhmm-B###
then
vyyyymmdd-hhmm-B###.Final (or vyyyymmdd-hhmm-B###.GA for product)
* for nightlies & releases toward maintenance builds
M-M1-yyyymmdd-hhmm-B###
S-CR1-yyyymmdd-hhmm-B###
then
vyyyymmdd-hhmm-B###.Final (or vyyyymmdd-hhmm-B###.GA for product)
(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.)
By using the I, M, S, and v convention, you ensure that:
* 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.
* 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.
* release builds are always newer than stables, milestones, or
maintenance builds, because v > S > M > I.
(Aside: if you don't like "v", we could also use "r", or any other
lowercase letter.)
N
On 08/24/2012 01:13 PM, Denis Golovin wrote:
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
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com