On Wed, Mar 1, 2017 at 12:16 AM, Max Rydahl Andersen <manderse@redhat.com> wrote:
On 28 Feb 2017, at 21:42, Mickael Istria wrote:

> On 02/28/2017 07:24 PM, Max Rydahl Andersen wrote:
>> sounds awesome if you guys found a way to deal with having to
>> manually eep these from not overlapping and avoid rerelasing
>> different bits with the same version number.
> This was:
> * https://issues.jboss.org/browse/JBIDE-13671
> * https://issues.jboss.org/browse/JBIDE-19056
> * https://issues.jboss.org/browse/JBIDE-22689

none of these seem to be new ? these was what was fixe ages ago.

So the version changes provides no benefits and becomes harder to keep
track on ?

Before it could be done more or less automated. Just thought it was
changing because you guys found a benefit to do so.
No, just to lower the load during updates. It is now possible because less components are being changed now (mainly OpenShift; server and base) 

>> Will this mean that builds and release now only update the actual
>> changed plugins ?
Yes 
>> and download diff will be smaller too ?
Yes 
> At least, the build infrastructure makes it possible and safe to
> update plugins only when necessary, with the benefit mentioned above
> (among others)

So is that a yes or no ?

>> btw. how come stopping to do the 3.3.0, 3.3.100 etc. as is standard
>> in
>> p2/eclipse ?
> This versioning pattern is only useful if JBoss Tools properly manages
> API versions and relies on API tools for guidance and checks. Last
> time I heard about it, it was far from being the case.

Not really, it is to allow updates by us or others in both branches
without colliding in p2 updates without having to rely on the fragile
date/timestamp pattern.

API versioning was secondary concern here.

/max
http://about.me/maxandersen
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev