Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Plugin Version Numbers in CDT 8.3

I¹m not sure I¹d be brave enough to mix plug-in versions like you¹re
doing. We¹ve always treated CDT as a single version. The plug-ins were
partitioned like they are to allow optionality, certainly not mixing and
matching versions.

Doug.

On 1/22/2014, 9:50 AM, "Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx> wrote:

>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Christian Walther
>> Sent: Wednesday, January 22, 2014 8:17 AM
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] Plugin Version Numbers in CDT 8.3
>> 
>> William.Riley@xxxxxxxxxxx wrote:
>> > I have been trying out the latest CDT 8.3 (building locally from the
>>8.3
>> branch) and noticed there are a number of plugins where the version
>> number is lower in 8.3 than in 8.2.1. e.g.
>>org.eclipse.cdt.managedbuilder.ui
>> is at version "8.2.1.qualifier" in CDT 8.2.1 but the last CDT 8.3 has
>>version
>> "8.2.0.qualifier".
>> 
>> Possibly related: We have noticed here that org.eclipse.cdt.debug.ui has
>> had API added in 3e847514
>> 
>>(org.eclipse.cdt.debug.internal.ui.disassembly.dsf.IDisassemblyBackend.ca
>> nDisassemble()) that is consumed by org.eclipse.cdt.dsf.ui, but its
>>version
>> number is still the same "7.3.0.qualifier" and org.eclipse.cdt.dsf.ui
>>still
>> requires the same "6.1.0" as in CDT 8.2.1. This allowed the
>> org.eclipse.cdt.dsf.ui from CDT 8.3.0 (built by us) to install together
>>with
>> org.eclipse.cdt.debug.ui from CDT 8.2.1 (from the official update site),
>> which resulted in runtime errors when trying to use the disassembly view
>> (NoSuchMethodError at
>> 
>>org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart.gotoFra
>> me(DisassemblyPart.java:2266)).
>> 
>> I'm rusty about what the rules are for versioning internal API, so this
>>may or
>> may not actually be a problem. For now we solved it by requiring the
>>whole
>> CDT 8.3.0 feature, not just individual plugins.
>
>I'm also not completely comfortable with the CDT version policy.
>However, I'm pretty sure that committers don't pay attention to version
>requirements when making changes.  In fact, I think we should remove
>all versions in our plugin dependencies to avoid mistakenly requiring
>a specific version instead of a version greater or equal to something.
>
>As for the error you encountered, I think there is an implicit requirement
>in the CDT that if you rebuild a plugin from a certain commit, you should
>use all other CDT plugins provided by that same commit.
>
>You are right that updating the version dependency would  have caught
>that issue, but I haven't seen anyone using that mechanism...
>
>Again, that is my limited impression, and I hope someone will correct
>me if I got this wrong.
>
>Marc
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top