As in this example , we'll move to x.(y+1).0 in master, and can move to
x.y.(z+1) in 4.4.x if required:
Max, we can still use the convention of moving from x.y.z to x.y.100 in
master (while 4.4.x reserves the right to move to x.y.(z+1) if required),
for projects which aren't in need of a MINOR update, but only SERVICE
changes. For example, a project that's not evolving like Portlet did this a
couple years ago:
On Tue, Feb 28, 2017 at 1:24 PM, Max Rydahl Andersen <manderse(a)redhat.com>
On 28 Feb 2017, at 18:11, Jean-Francois Maury wrote:
> as we branched for Oxygen, we now have two different branches to
> and as we are pushed changes in the code base, we need to upversion
> In order to be better aligned with OSGI/P2, we decided to change a
> how the bump is managed.
> Previously, all sub-components of a component (eg
> were upversioned as soon as a single sub component is modified). We
> upversion only the sub component that has changed.
> For master, the minor will be incremented and for 4.4.x, the micro
> will be
> As an example, we need to update org.jboss.tools.openshift.client in
> branches and as OpenShift is 3.3.2, this will give:
> - master: org.jboss.tools.openshift.client only will switch to
> - 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
from not overlapping and avoid rerelasing different bits with the same
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
jbosstools-dev mailing list
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio