[jbosstools-dev] Plugin versions

[Denis Golovin]

On 02/06/2013 11:13 AM, Nick Boldt wrote:
> 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.

It is going to be JBoss Developer Studio (Kepler) I really would like to 
have installation failed for Juno, to avoid flow of errors about 
class/methods not being found and alike problems.

Vice versa now JBoss Tools (Juno) doesn't show it is actually cannot be 
installed on Kepler, because Hibernate Tools is affected by changes in 
Dali API. Should we release 4.0.1 with fixed hibernate tools dependencies?

Denis

>
> 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 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
>>
>