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