[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