[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [papyrus-rt-dev] Preparing Papyrus-RT for the Eclipse Marketplace
|
I don’t know that you could reasonably test the difference between [3.0.0,5.0.0) and [3.0.0,4.0.1). Besides that the scheme will break when the dependency has a service update to 4.0.1 which a user should be able to install irrespective of anything else because it has only bug fixes.
Cheers,
Christian
On Oct 6, 2017, 12:01 -0400, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
That's a very good point indeed. We could be breaking some people's clients, and now that we have 446 downloads of the RCP, we can no longer assume that our changes would have only a limited effect.
As far as I'm concerned, we should release it as 1.0.1. Any objections?
A question: the changes that I've made to several version ranges on our dependencies where from [3.0.0,4.0.0) to [3.0.0,5.0.0). Am I increasing the range too much? Would it be preferable to increase them to [3.0.0,4.1.0) or [3.0.0,4.0.1)?
--
Ernesto
If it helps, I agree with your assessment.
Changing the version range of a dependency potentially changes the class space of users of the bundle, and the possible wirings in the OSGi framework. So that really does seem to need a new version number.
Cheers,
Christian
On Oct 5, 2017, 12:24 -0400, Ernesto Posse <
eposse@xxxxxxxxxxxxx>, wrote:
I've ran into a number of issues regarding this preparation for the Marketplace.
The story is this: in order to publish the changes required on the feature.xml files we need to build, but the build fails because one dependency (the Papyrus JUnit framework) is available only in a nightly update site so only its latest version is available and this requires some bundles that have been backported from Photon into the Papyrus streams/3.0-maintenance branch but these had not been published. After some discussions in the Papyrus dev mailing list, they have published a Papyrus 3.2 milestone with the updated, backported bundles. So as part of Gerrit
106163 I've updated our TPs to use that new 3.2 milestone update site to obtain the Papyrus SDK. The problem is that several of our plugins have dependencies with version ranges [3.0.0,4.0.0) on plugins which have been backported. So in that same Gerrit I've increased the version range in the relevant MANIFEST.MF files to [3.0.0,5.0.0). Now, one issue is that we had previously discussed that we didn't need to bump the version number to 1.0.1, but I was reading the guidelines at [1] and they state:
"The service segment number must be incremented whenever there have been changes to a plug-in between releases that are not visible in its API. For example, a bug has been fixed in the code, the plug-in manifest has changed, documentation has changed, compiler settings have changed."
So it looks like we would have to increase the version number. Any thoughts on this?
I'm also running into other build issues. Apparently the new Papyrus 3.2 build is not compatible with the Papyrus Interoperability RSA feature that we need in our RSA-RTE import feature.
Great, I'll do that. Good to know I won't have to do one of those big version-changing gerrits ;) We should really have a script for that.
--
Ernesto
The “1.0a” is just a marketing version name so, no, just the publication URL as you suggested and I suppose also hyperlink text on the Papyrus-RT web pages and wikis, etc.
Cheers,
Christian
On Oct 4, 2017, 12:23 -0400, Ernesto Posse <
eposse@xxxxxxxxxxxxx>, wrote:
Hi, Ernesto,
Sounds good. But, the new build will have new qualifiers for the feature versions, so probably it should be published as a Papyrus-RT 1.0a (yay a-builds) as a separate child repository of the composite, not replacing the previous bits. For complete and accurate release history and reproducibility for dependents.
Hello all. This is a quick note to inform everyone that we are preparing to add Papyrus-RT to the Eclipse Marketplace.
Our plan is to provide listings for both the RCP and the update site, but in order to do this, we need to do a some small maintenance to our 1.0 release because an installation using the update site fails to resolve some dependencies. In particular, the features that fail to be installed are the C++ feature, the RSA-RTE importer feature and Codegen. The dependencies that fail are the following:
C++: org.eclipse.papyrus.designer.languages.cpp.library 0.7.0
Codegen: org.eclipse.papyrus.designer.languages.common.base [1.0.4,2.0.0)
RSA-RTE Importer: org.eclipse.papyrus.interoperability.rsa [1.4.0,2.0.0)
The last is available from the Papyrus Interoperability component available from
So we need to make some small adjustments to a couple of features, more precisely to their meta-data.
We need to add the URLs above as "discovery" URLs to the corresponding feature.xml. I have already done that with Gerrit
106163. Unfortunately the build fails because the TPs fails to resolve a transitive dependency of the Papyrus JUnit feature. I've been discussing this in the Papyrus Developers mailing list (see thread
https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg04137.html)
So once the build issue is resolved, we will publish a "new" release. It will still be 1.0.0 but with a slightly different qualifier. After discussing with Christian, it seems that we do not need to bump the version to 1.0.1 since we are only modifying some meta-data. I will announce here when the new build is available, and when the Marketplace listing is up.
Incidentally, if you don't install the C++, Codegen and RSA Importer features, you are unable to create models! But that's a different issue. I'll open a bug for that.
--
Ernesto Posse
Zeligsoft
--
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
--
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
