As of Service Discovery 2.0, all API is considered provisional.
This means, that we reserve the right to change any API after -Service Discovery 2.0 in a not backward compatible way. All such API changes -will be voted on by committers on the +Service Discovery 2.0 in a not backward compatible way. +We will make every sensible effort to keep at least Source API +Compatibility intact, but in cases where this would lead to unnecessary +code bloat we will go with API breakage. +All such API changes will be voted on by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a stable, hardened API for Service Discovery 3.0. Please give your feedback on diff --git a/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html b/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html index f93f864d63d..92adea2bca0 100644 --- a/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html +++ b/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html @@ -4,7 +4,7 @@
Although RSE API has been reviewed and proven useful in earlier proprietary -versions, we want to give the Open Source Communitiy a chance to provide public -feedback and help further improving the APIs. Therefore,
+versions, we want to give the Open Source Communitiy a chance to provide more +public feedback and help further improving the APIs. Therefore, -As of RSE 1.0, all API is considered provisional.
+As of TM / RSE 2.0, all API is considered provisional.
-This means, that we reserve the right to change any API after RSE 1.0 -in a not backward compatible way. All such API changes will be voted on +
This means, that we reserve the right to change any API after TM / RSE 2.0 +in a not backward compatible way. We will make every sensible effort to +keep at least Source API Compatibility intact, but in cases where this would +lead to unnecessary code bloat we will go with API breakage. All such API changes will be voted on by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a -stable, hardened API for RSE 2.0. Please give your feedback on +stable, hardened API for TM 3.0. Please give your feedback on Eclipse Bugzilla under category DSDP, Product Target Management.
Although RSE API has been reviewed and proven useful in earlier proprietary -versions, we want to give the Open Source Communitiy a chance to provide public -feedback and help further improving the APIs. Therefore,
+versions, we want to give the Open Source Communitiy a chance to provide more +public feedback and help further improving the APIs. Therefore, -As of RSE 1.0, all API is considered provisional.
+As of TM / RSE 2.0, all API is considered provisional.
-This means, that we reserve the right to change any API after RSE 1.0 -in a not backward compatible way. All such API changes will be voted on +
This means, that we reserve the right to change any API after TM / RSE 2.0 +in a not backward compatible way. We will make every sensible effort to +keep at least Source API Compatibility intact, but in cases where this would +lead to unnecessary code bloat we will go with API breakage. All such API changes will be voted on by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a -stable, hardened API for RSE 2.0. Please give your feedback on +stable, hardened API for TM 3.0. Please give your feedback on Eclipse Bugzilla under category DSDP, Product Target Management.