[jbosstools-dev] change to have build_alias in front

[Max Rydahl Andersen]

On 24 Aug 2012, at 06:20, Nick Boldt <nboldt at redhat.com> wrote:

> Well, there's always the option of having the timestamp PRECEDE the alias, like for the last 2 releases. :)

no there is not - we have gone through the disadvantages of this so many times.

> That way it's up to the user to decide if they want to upgrade from 1.2.3.v20120824-1234-M2 to the next dev milestone 1.2.3.v20120924-2345-Beta1 or stick to nightlies.
> 
> By switching to alias-first, you force a preferred sequence on the user and remove the option for that user to select which upgrade path they want -- to the stable branch or to the next trunk nightly.

not following you. please elaborate - i'm seeing it as we are securing the update path is correct and much less likely to fail.

> But by starting with a timestamp, as long as the update was built after the current, you can select that as an upgrade path (or pick an older newer build). Then you can call the milestone whatever you want, be it M1 or Alpha1. (This is why I pushed for this convention in the first place.)

It is bogus.

take fedora17 repackaging - bang, a rebuild is done of older version, now it is never than everything else even though that is false/wrong.

> There's also the option of adopting Eclipse's Itimestamp (integration build) or Mtimestamp (maintenance build) and vtimestamp (release build) convention. This is how projects like Mylyn, for example, handle weekly builds (I lead up to a .0 release, M lead up to .1 and .2 releases) vs. their final/GA release builds, since I and M are always "older" ASCII-wise than v, and M is always "newer" than I so a maintenance build will trump a pre-GA build.

hmm - thats a variation of the eclipse conventions I don't know - never seen M refeer as maintancne, always been milestone afaik.

Any docs on this on eclipse.org ?

/max
> 
> Nick
> 
> On 08/23/2012 11: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
>> 
>> 
>> _______________________________________________
>> 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
> 
>