<div dir="ltr">As in this example [1], we&#39;ll move to x.(y+1).0 in master, and can move to x.y.(z+1) in 4.4.x if required:<div><br></div><div>[1] <a href="https://github.com/jbosstools/jbosstools-livereload/pull/137">https://github.com/jbosstools/jbosstools-livereload/pull/137</a><br></div><div><br></div><div>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&#39;t in need of a MINOR update, but only SERVICE changes. For example, a project that&#39;s not evolving like Portlet did this a couple years ago:</div><div><br></div><div><a href="https://github.com/jbosstools/jbosstools-portlet/commit/a4cad711480623bfa2652d46c98a3f57099671f6">https://github.com/jbosstools/jbosstools-portlet/commit/a4cad711480623bfa2652d46c98a3f57099671f6</a><br></div><div><br></div><div>Nick</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 1:24 PM, Max Rydahl Andersen <span dir="ltr">&lt;<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28 Feb 2017, at 18:11, Jean-Francois Maury wrote:<br>
<br>
&gt; Hello,<br>
&gt;<br>
&gt; as we branched for Oxygen, we now have two different branches to<br>
&gt; maintain<br>
&gt; and as we are pushed changes in the code base, we need to upversion<br>
&gt; the<br>
&gt; components.<br>
&gt; In order to be better aligned with OSGI/P2, we decided to change a<br>
&gt; little<br>
&gt; how the bump is managed.<br>
&gt; Previously, all sub-components of a component (eg<br>
&gt; jbosstools-openshift)<br>
&gt; were upversioned as soon as a single sub component is modified). We<br>
&gt; will<br>
&gt; upversion only the sub component that has changed.<br>
&gt; For master, the minor will be incremented and for 4.4.x, the micro<br>
&gt; will be<br>
&gt; increment.<br>
&gt;<br>
&gt; As an example, we need to update org.jboss.tools.openshift.<wbr>client in<br>
&gt; both<br>
&gt; branches and as OpenShift is 3.3.2, this will give:<br>
&gt;<br>
</span>&gt;    - master: org.jboss.tools.openshift.<wbr>client only will switch to<br>
&gt; 3.4.0<br>
&gt;    - 4.4.x: org.jboss.tools.openshift.<wbr>client only will switch to 3.3.3<br>
<br>
sounds awesome if you guys found a way to deal with having to manually<br>
keep these<br>
from not overlapping and avoid rerelasing different bits with the same<br>
version number.<br>
<br>
Will this mean that builds and release now only update the actual<br>
changed plugins ?<br>
and download diff will be smaller too ?<br>
<br>
btw. how come stopping to do the 3.3.0, 3.3.100 etc. as is standard in<br>
p2/eclipse ?<br>
<br>
<br>
/max<br>
<a href="http://about.me/maxandersen" rel="noreferrer" target="_blank">http://about.me/maxandersen</a><br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
jbosstools-dev mailing list<br>
<a href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/jbosstools-<wbr>dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Nick Boldt :: JBoss by Red Hat<br>Productization Lead :: JBoss Tools &amp; Dev Studio<br><a href="http://nick.divbyzero.com" target="_blank">http://nick.divbyzero.com</a><br></div></div></div></div>
</div>