On 08 Feb 2013, at 14:25, Denis Golovin <dgolovin(a)exadel.com> wrote:
> Should we then:
> 1. Update eclipse deps to kepler which would not let install on Juno?
Depends on the component - component owners would know this.
> 2. Bump minor version everywhere, now some components have bumped only patch version
(example is server/as)
As we have *always* done we need to bump more than just x.y.z+1 when we got two different
branches for juno and one for kepler.
If a component really think it has all the API's and dependencies be perfect then
they can just do a .z bump but then it has to be a x.y.z+100 to avoid collisions with the
4.0.x branch builds.
I'm not following why this is so hard to grasp - we've done this *every* year.
Why is it so hard to do this time ? :)
/max
>
> Denis
>
> On 02/08/2013 11:16 AM, Max Rydahl Andersen wrote:
>> On 06 Feb 2013, at 04:07, Mickael Istria <mistria(a)redhat.com> wrote:
>>
>>> I would recommend using these rules
http://wiki.eclipse.org/Version_Numbering
, but Max & others should confirm whether we want to follow them of not:
>>> These rules are, according to the delta between last release and current
work:
>>> * Bugfix: increment micro
>>> * New feature: increment minor
>>> * Broken API (removed or renamed some public methods or classes): increment
major.
>>> However it's an habit that plugin follow also the versioning pattern of
there release train (Eclipse for WTP, JBT for our components).
>> These are the rules we follow and we take the consequence of our builds and
dependencies currently forcing us to bump x.y+1 since kepler becomes a requirement and
thus it has new features in 80% of our plugins.
>>
>> The day we actually stop building from two branches for *everything* we can start
versioning more "pure osgi" like.
>>
>> /max
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
_______________________________________________
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