|
|
|
|
|
| Re: Rayo versions [message #1013498 is a reply to message #1013023] |
Sat, 23 February 2013 20:19   |
 Lukas Huser
Messages: 42
Registered: March 2010 |
Member |
|
|
Hi all
Quote:
We should also talk about API changes / extensions within a SR release. In my opinion if an API is extended for an upcoming SR, other products (like our Marketplace products) should not use this API if they are targeted for the same SR release.
If we switch to a new major release (e.g. Scout 3.9), the new API can be used of course.
Incompatibility of Scout bundles between different service releases (in OSGi terms: increasing the micro part of the version) does also affect the Scout core bundles itself. For example scout.rt.client 3.8.1 requires at minimum scout.rt.shared 3.8.1 and is not compatible with scout.rt.shared 3.8.0. See related forum thread: http://www.eclipse.org/forums/index.php/t/456019
While semantic versions of OSGi bundles (as described in the link provided by Jérémie) seems to be a nice concept, I don't think that it is practical for the Scout project, especially if the version numbers are dictated by the Eclipse release train.
Following OSGi semantic versions, you wouldn't even be allowed to introduce a new API method in a new service release (as it breaks the API for implementers)! And it would mean that e.g. scout.rt.client 3.8.x must compile against all versions of scout.rt.shared >= 3.8.0. Personally, I think this is too restrictive. The basic bundles (such as scout.rt.shared or scout.commons) should be allowed to provide new API methods, dependent bundles (such as scout.rt.client or scout.rt.server) should be allowed to profit from them, also within a service release. It would mean that the Scout bundles are only guaranteed to be compatible against each other within the same micro version, but not necessarily within the same minor version. Or in other words: if you switch to a new service release, you must update all Scout bundles to the same service release.
Also, following OSGi semantic versions, it would not be allowed to break the API for existing consumers with a new minor release (e.g. going from 3.8 to 3.9). But I think this is common practice in the Scout project, as you usually have a migration guide when changing from one minor version to the next.
I think it would help if the Scout project clearly defined its versioning and compatibility policy, which need not necessarily be OSGi semantic versions. But the chosen compatibility policy should also be reflected in the manifest files of the respective bundles (i.e. defining the correct version range of a required bundle).
Quote:
It is allowed in the version 3.8.2 of Rayo to requires a org.eclipse.scout.rt.ui.swing 3.8.2?
So, yes, in my opinion, you should be allowed to use the new API method and bump the version of the required bundle. I would prefer this approach over "inlining" (meaning: copy) the method from the required bundle. It might be justified in this specific case (I don't know the code), but in general, this is certainly a bad idea.
Just my two cents 
Lukas
|
|
|
| Re: Rayo versions [message #1014873 is a reply to message #1013498] |
Tue, 26 February 2013 16:11 |
Ken Lee
Messages: 97
Registered: March 2012 |
Member |
|
|
Hi Lukas,
Thanks for your helpful input.
Quote:
...
Personally, I think this is too restrictive. The basic bundles (such as scout.rt.shared or scout.commons) should be allowed to provide new API methods, dependent bundles (such as scout.rt.client or scout.rt.server) should be allowed to profit from them, also within a service release. It would mean that the Scout bundles are only guaranteed to be compatible against each other within the same micro version, but not necessarily within the same minor version. Or in other words: if you switch to a new service release, you must update all Scout bundles to the same service release.
I agree that the OSGI semantic versioning is too restrictive for Scout. I also acknowledge that an API change inside the bundle scout.commons should be used for example by font=Courier]scout.rt.client[/font] or scout.rt.server within a minor release as long as they belong to the same feature. Currently (Scout 3.9 Nightly Updatesite), we have the following important features:
- Scout Runtime
- Scout Runtime RAP
- Scout Runtime RAP Testing
- Scout Runtime Testing
- Scout SDK
- Scout SDK RAP
Additionally, there are features for JDBC and Rayo (Marketplace). My proposal is to allow consuming API changes within bundles that are located in the same feature but using changed APIs of a bundle in a different feature is prohibited.
E.g. In Scout Runtime version 3.8.2 a new method in SwingUtility was added that was used in Rayo 3.8.2. Since SwingUtility is not part of the Rayo feature, it's prohibited for the Rayo bundle to call that method.
What do you think about that?
Quote:
Also, following OSGi semantic versions, it would not be allowed to break the API for existing consumers with a new minor release (e.g. going from 3.8 to 3.9). But I think this is common practice in the Scout project, as you usually have a migration guide when changing from one minor version to the next.
I absolutely agree that introduced API changes within a SR release are allowed to be consumed in the upcoming major release.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03761 seconds
] 
Search
Help
Register
Login
Home
