[jbosstools-dev] Plugin versions

[Nick Boldt]

Reference doc on how/when/why to upversion:

http://wiki.eclipse.org/Version_Numbering#Overall_example

Cheers,

Nick

On 02/08/2013 03:05 PM, Max Rydahl Andersen wrote:
>
> 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
>>
>
>
> _______________________________________________
> 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