[jbosstools-dev] change to have build_alias in front

[Nick Boldt]

Right, we have already established that I'm the only one who likes 
timestamp-first qualifiers.

Thus question is simply:

a) do we use Eclipse conventions (I, M, S, then r or v) to prefix the 
M1, M2, Beta1, CR1, Final, GA labels?

or

b) do we use Alpha1, Alpha2, Beta1, CR1, Final, GA instead, because 
Alpha sounds really unstable, whereas Milestone sounds like something 
worth trying out as an early adopter ?


On 08/24/2012 02:47 PM, Denis Golovin wrote:
> -1 for using timestamps first in qualifier, I spent to much time
> figuring out why builds were failing
>
> +1 to follow the rules
> {quote}
> major.minor.micro.Alpha[n]
> major.minor.micro.Beta[n]
> major.minor.micro.CR[n]
> major.minor.micro.Final
> {quote}
>
> with modifications
>
> major.minor.micro.Alpha[n]-vYYYYMMDD-HHMM-Hnnn
> major.minor.micro.Beta[n]-vYYYYMMDD-HHMM-Hnnn
> major.minor.micro.CR[n]-vYYYYMMDD-HHMM-Hnnn
> major.minor.micro.Final-vYYYYMMDD-HHMM-Hnnn
>
> 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.
> 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.
>
> Denis
>
> On 08/24/2012 11:05 AM, Nick Boldt wrote:
>> 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 at 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