"We will upversion only the sub component that has changed." Does that mean "only increment the plugin and its containing feature when a change happens in a given plugin; for all other plugins/features don't bump for the sake of bumping" ? Or does that mean "if in jbosstools-base, only foundation and common have changed, but the sub components called usage, runtime, tests, and stacks have not, then only the features and plugins in foundation and common should be mass-bumped to x.y+1 (master) or x.y.z+1 (4.4.x branch)" ? By the way, if you forget to increment a feature that contains your changed plugin, the baseline comparator will complain when you build locally: [ERROR] Failed to execute goal compare-version-with-baselines on org.jboss.tools.openshift.core: Version have moved backwards for (org.jboss.tools.openshift.core/3.3.2.v20170215-1207). Baseline has 3.3.2.v20170217-1329) So you can verify you've bumped all the right things by iterating until the errors go away. On Tue, Feb 28, 2017 at 12:11 PM, Jean-Francois Maury <jmaury(a)redhat.com&gt; wrote: > Hello, > > as we branched for Oxygen, we now have two different branches to maintain > and as we are pushed changes in the code base, we need to upversion the > components. > In order to be better aligned with OSGI/P2, we decided to change a little > how the bump is managed. > Previously, all sub-components of a component (eg jbosstools-openshift) > were upversioned as soon as a single sub component is modified). We will > upversion only the sub component that has changed. > For master, the minor will be incremented and for 4.4.x, the micro will > be increment. > > As an example, we need to update org.jboss.tools.openshift.client in > both branches and as OpenShift is 3.3.2, this will give: > > - master: org.jboss.tools.openshift.client only will switch to 3.4.0 > - 4.4.x: org.jboss.tools.openshift.client only will switch to 3.3.3 > > We will experiment this during 4.4.4.AM1 and revisit if we found too many > problems > > _______________________________________________ > 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

On 28 Feb 2017, at 18:11, Jean-Francois Maury wrote: > Hello, > > as we branched for Oxygen, we now have two different branches to > maintain > and as we are pushed changes in the code base, we need to upversion > the > components. > In order to be better aligned with OSGI/P2, we decided to change a > little > how the bump is managed. > Previously, all sub-components of a component (eg > jbosstools-openshift) > were upversioned as soon as a single sub component is modified). We > will > upversion only the sub component that has changed. > For master, the minor will be incremented and for 4.4.x, the micro > will be > increment. > > As an example, we need to update org.jboss.tools.openshift.client in > both > branches and as OpenShift is 3.3.2, this will give: > > - master: org.jboss.tools.openshift.client only will switch to > 3.4.0 > - 4.4.x: org.jboss.tools.openshift.client only will switch to 3.3.3 sounds awesome if you guys found a way to deal with having to manually keep these from not overlapping and avoid rerelasing different bits with the same version number. Will this mean that builds and release now only update the actual changed plugins ? and download diff will be smaller too ? btw. how come stopping to do the 3.3.0, 3.3.100 etc. as is standard in p2/eclipse ? /max http://about.me/maxandersen _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

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

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

> 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.

On Wed, Mar 1, 2017 at 12:16 AM, Max Rydahl Andersen <manderse(a)redhat.com&gt; 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)

On 03/01/2017 11:19 AM, Max Rydahl Andersen wrote: > Next week I install into a new jboss server tools ...do I get the > exact same bits as the one I downloaded a week ago ? or is this a new > set of binaries just with the same 4.3.0 number ? With https://issues.jboss.org/browse/JBIDE-22689 and https://issues.jboss.org/browse/JBIDE-19056, it's the same bits.