[jbosstools-dev] Plugin versions

Max Rydahl Andersen max.andersen at redhat.com
Fri Feb 8 15:05:01 EST 2013


On 08 Feb 2013, at 14:25, Denis Golovin <dgolovin at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 




More information about the jbosstools-dev mailing list