4

I am having much confusion over the process of upgrading version numbers in dependent plug-ins, features, and products in a fairly large eclipse workspace.

I have made API changes to java code residing in an existing plug-in and thus requires an increase of the Major part of the version identifier. This plug-in serves as a dependency to a given feature, where the feature is later included in a product. From the documentation at http://wiki.eclipse.org/Version_Numbering, I understand (for the most part) when the proper number should be increased on the containing plug-in itself.

However, how would this Major version number change on the plug-in affect dependent, "down-the-line" items (e.g., features, products)?

For example, assume we have the typical "Hello World" setup as follows:

Plug-in: com.example.helloworld, version 1.0.0
Feature: com.example.helloworld.feature, version 1.0.0
Product: com.example.helloworld.product, version 1.0.0

If I were to make an API change in the plug-in, this would require a version update to be that of 2.0.0. What would then be the version of the feature, 1.1.0? The same question can be applied for the product level as well (e.g., if the feature is 1.1.0 OR 2.0.0, what is the product version number)?

I'm sure this is quite the newbie question so I apologize for wasting anyone's time and effort. I have searched for this type of content but all I am finding is are examples showing how to develop a plug-in, feature, product, and update site for the first time. The only other content related to my search has been developing feature patches and have not touched on the versioning aspect as much as I would prefer. I am having difficulty coming into (for the first time) an Eclipse RCP / PDE environment and need to learn the proper way and / or best practices for making such versioning updates and how to best reflect this throughout other dependent projects in the workspace.

user229044
  • 232,980
  • 40
  • 330
  • 338
Michael
  • 786
  • 8
  • 18

1 Answers1

1

If you would like to apply the same versioning systems to feature and product, then you would set feature and product to 2.0.0 when one of the plugins go to 2.0.0. That would communicate to whoever is consuming your feature or product that there is a breaking API change inside it somewhere.

On the other hand, there is no requirement to apply the same versioning convention. You can version your bundles following that convention to properly communicate your API changes and then turn around and use more marketing-sensible versions for product/feature. Keep in mind that user will see product/feature version more than they will individual bundle version.

I've seen it done both ways effectively. There isn't really a right or wrong way on this.

Konstantin Komissarchik
  • 28,879
  • 6
  • 61
  • 61
  • Thanks Konstantin, that does answer my question. Where I am at, I am seeing a combination of versioning schemes that either follow exactly what the recommendations are OR have assumed a fixed version in source control for a later, official release and have kept change code under this version. I keep second guessing as to which route to follow. – Michael Jan 28 '11 at 22:43
  • This is one topic that I haven't seen much general agreement on. While Eclipse/OSGi recommended versioning convention makes a lot of sense from engineering standpoint, the convention is extremely time-consuming and error-prone to apply on a code base of any size. You basically have to know how version has incremented already in the release and whether you need to change it, with every code change. I have yet to meet an engineer who can do this reliably time and time again. – Konstantin Komissarchik Jan 28 '11 at 22:47
  • Continuation... Frankly, I think we have better things to think about, which is why on projects that I have ability to set convention on I have adopted a simpler variation. At the start of the release, you decide what type of changes are going to be allowed. From that you derive a version number using the Eclipse/OSGi convention as if the change has taken place. You then stamp that version number across all bundles, features, etc. at the start of the release and don't think about it again. – Konstantin Komissarchik Jan 28 '11 at 22:49
  • I've already sent the email off requesting background on versioning in the product I am working on, specifically what is expected, preferred, adopted, etc. I agree on the usage of version numbers at the beginning of the release. In the end, what matters for versions to be compatible at all levels (e.g., plug-ins, features, bundles, etc.) is when the are ultimately released for usage by the customer (initial install and updates down the road). Thank you for the help and insightful tips! – Michael Jan 28 '11 at 23:01