[jbosstools-dev] Versions bump policy change
Jean-Francois Maury
jmaury at redhat.com
Tue Feb 28 13:18:47 EST 2017
Nick,
yes that the idea. This is following what you've done with your PR's for
fixing master (livereload,...) except that we will increment mini in master
On Tue, Feb 28, 2017 at 7:09 PM, Nick Boldt <nboldt at redhat.com> wrote:
> "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 at redhat.com>
> 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20170228/e72dc39a/attachment-0001.html
More information about the jbosstools-dev
mailing list