Hi guys,

I have a question regarding updating plugin/feature version for JBT 4.1.0.Alpha. Should we just increment N in x.N.y for all the plugins/features versions which we changed even if it was just a minor bug fixing?

Should we change Eclipse (wtp, etc.) dependencies in plugin.xml too even if we don't use any new API from Kepler?

On 02/06/2013 01:07 AM, Mickael Istria wrote: > >> Should we change Eclipse (wtp, etc.) dependencies in plugin.xml too even >> if we don't use any new API from Kepler? > No, you shouldn't do it. MANIFEST.MF must contain the "wider" > compatible version range. The problem is that we don't know if JBT compatible with Juno until we test it against Juno, do we?

Yes, the plan is to have JBT 4.1 / JBDS 7.0 install on Kepler (not Juno) and keep JBT 4.0 / JBDS 6.0 as the Juno- (not Kepler-) compliant version. BTW, I believe for this cycle the plan is to only submit JBDS 7 to the Marketplace, rather than having BOTH JBT 4.1 and JBDS 7 entries. The logic here is that since they're about 98% duplicate content, there's little point having both there.

N On 02/06/2013 02:10 PM, Denis Golovin wrote: > It worth to update dependencies to Kepler version: > 1. Hibernate Tools depends on Dali that requires Kepler; > 2. JBoss Tools are going to be called on JBoss Tools (Kepler) in Eclipse > marketplace. > > If we let install JBoss Tools on Juno and Kepler, devs can install for > example CDI Tools Feature on Juno and then try to add Hibernate Tools > and installation would fail. > > I would prefer to have installation behavior that matches the name > "JBoss Tools (Kepler)", which means it is installable only on Kepler and > fails for Juno. > > Denis > > On 02/06/2013 10:09 AM, Mickael Istria wrote: >> On 02/06/2013 06:58 PM, Alexey Kazakov wrote: >>> On 02/06/2013 01:07 AM, Mickael Istria wrote: >>>> >>>>> Should we change Eclipse (wtp, etc.) dependencies in plugin.xml >>>>> too even >>>>> if we don't use any new API from Kepler? >>>> No, you shouldn't do it. MANIFEST.MF must contain the "wider" >>>> compatible version range. >>> >>> The problem is that we don't know if JBT compatible with Juno until >>> we test it against Juno, do we? >> We'll test only for Kepler. But you can expect it to work or not with >> Juno. >> Next JBT will only be supported (ie guaranteed to work on Kepler), but >> if you think your component still support Juno, you'd better not >> change versions in MANIFEST because: >> 1. Some people may want to install your component on Juno, and will be >> happy if it works. If it doesn't work, it's not that bad because we >> don't support it. >> 2. It's more effort and risk for you to change MANIFEST. >> 3. If we change our mind and decide to support Juno, you won't have >> anything to change. >> So I recommend you change MANIFEST only when you _need_ it (ie when >> you have some breaking API or feature changes in your dependencies). >> >> If your stuff can still work on Juno, changing versions in MANIFEST >> will make it impossible to use it on Juno. There is no added-value to >> it. The target-platforms provide all the safety you need. >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> My blog <http://mickaelistria.wordpress.com> - My Tweets >> <http://twitter.com/mickaelistria> >> >> >> _______________________________________________ >> 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 >

I have the opposite feeling: some people will be happy to see them working on Juno. Why updating MANIFEST and block that? What is the added value?

IMO we just don't know if the stuff works on Juno if we don't test it on Juno and even don't build it against Juno.

On 06 Feb 2013, at 04:07, Mickael Istria <mistria(a)redhat.com&gt; 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

On 08 Feb 2013, at 14:25, Denis Golovin <dgolovin(a)exadel.com&gt; 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&gt; 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