| Re: [mdt-papyrus.dev] Colliding version numbers between Oxygen and Photon? |
Hi Camille
No tool support is a bit of a pain, but for my projects I solve the problem by:
Add +0.0.100 to ALL plugins/features/... eagerly the day after the annual (major/minor) release. This guarantees no maintenance build clashes.
When updating a x.x.x00 plugin, the version can then be lazily changed to a +0.1.0.
Delaying the +0.0.100 to a convenient lazy point just about guarantees that with many developers someone will forget and the result is illegal builds.
I recommend that you do +0.0.100 to every plugin that hasn't had +0.1.0 already NOW. Then follow https://wiki.eclipse.org/Tycho
/Reproducible_Version_Qualifie rs
before you provide any builds to ensure that you do not have a negative qualifier time step in the new versions.
(The +0.0.100 on everything has the disadvantage that extremely stable plugins cannot be effectively cached. But Papyrus is not extremely stable and with current time qualifiers you have inhibited reuse anyway.)
Regards
Ed Willink
On 10/11/2017 14:30, Camille Letavernier wrote:
Hi Peter,
There are definitely some issues with the Papyrus release engineering. This is a big topic for a big project with many branches and repos (Bug/Feature branches, Component repos, Maintenance/Release branches...), plus many jobs (Build, test, gerrit, ...) with various stabilities (Nightly, release...). It's easy to get lost and miss some cases.
So there really are some issues. The build trigger times are supposed to be different between release versions (Oxygen vs Photon), but I guess it was an overlook when the Job was cloned to prepare the Photon branch. It shouldn't be difficult to fix.
Regarding the version schemes, that's also a complex topic, where the tooling doesn't scale very well (Especially for the Papyrus project, which initially didn't follow the API Tools convention during its incubation phase - and we realized a little bit late that if you don't follow these conventions from Day 1, it's pretty much impossible to get proper API management without refactoring the entire code base later on)
So Papyrus versioning is not perfect, and unfortunately won't be easily fixed.
I've had a look at the Version Numbering guidelines, and they seem to work well with the older Release Train schema, where we shipped Service Releases several times a year, and only one minor or major release a year. Since we now moved to Minor Releases scheme (Oxygen.1 instead of Oxygen SR1), we'd have to ship Papyrus 3.100 for Photon and Papyrus 3.x for Oxygen (Assuming we don't get any API break between Oxygen releases). And I don't think that API Tools would help maintaining these versions either - IIRC, it doesn't handle service segments at all, so many patches that don't affect the API are checked in without any version change.
For a project of this scale, it's nearly impossible to provide good versioning without perfect tool support - and unfortunately the tools that are configured today are not perfect, and would - at least - require a complete refactoring of Papyrus packages.
Cheers,
Camille
On Fri, Nov 10, 2017 at 3:06 PM, Cigehn Peter <Peter.Cigehn@xxxxxxxxx> wrote:
Hi,
The Oomph setup file I provided is *product* setup file for installing an end-user installation of the different Papyrus versions, i.e. this is used for testing Papyrus. I am not talking about the “normal” use of Oomph for setting up a development environment (in which case you in practice use an Oomph *project* setup file), i.e. used for developing Papyrus. Sorry for the confusion…
The Oomph product setup file that I attached in the previous can be added as a <User Product> using the green plus button above the list of products on the first page in advanced mode in the Eclipse Installer. Then in the drop-down list of “Product Version” you can select any of the nightly builds for the different tracks (Photon, Oxygen, Neon ...)
Here is a screen shot how it looks like in Eclipse Installer when you have added the setup file that I added using the marked green plus button (I also have another product setup file added for testing Papyrus-RT).
When installing an end-user installation of Papyrus, you will not select any of the projects on the second page in the wizard (which is more related to setting up a development environment).
Hope this makes it more clear what I am trying to explain regarding the use of Eclipse Installer and a shared bundle pool.
/Peter Cigéhn
From: mdt-papyrus.dev-bounces@eclips
e.org [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx ] On Behalf Of Ed Willink
Sent: den 10 november 2017 14:53
To: mdt-papyrus.dev@xxxxxxxxxxx
Subject: Re: [mdt-papyrus.dev] Colliding version numbers between Oxygen and Photon?
Hi
I'm confused. If you are installing the Papyrus OOMPH you don't download any Papyrus plugins since you will have Papyrus projects in your workspace. When I do a Papyrus OOMPH I get no 2017 Papyrus plugins in my P2 pool.
If you are doing something downstream then may be Papyrus gets fetched. So there may be multiple bugs/inefficiencies. You should be specifying a particular Papyrus version, perhaps you didn't. OOMPH should only download that version, perhaps it lazily loads multple versions. Even if OOMPH loads multiple versions inefficiently, those with the identical fully qualified name must offer identical functionality; it really doesn't matter whether you happen to install from Oxygen / Master.
I suspect that the releng bugs I identified earlier are the cause of problems.
Regards
Ed Willink
On 10/11/2017 12:44, Cigehn Peter wrote:
Hi,
Just to clarify what I tried to explain in my first mail: I am using the Eclipse Installer (Oomph) and thus utilize a shared p2 bundle pool. When there are colliding version numbers with identical time stamps in their qualifier, the shared p2 bundle pool gets “confused” (since it only can cache one of the bundles in the shared bundle pool, i.e. either the Oxygen or the Photon one). I have attached the Oomph setup file for anyone interested (and maybe want to try this out themselves). As you can see, the list of available repos are different, and there is no Photon repo when installing Oxygen (or vice versa). Depending on in which order you install/update you either “contaminate” the Photon installation with the Oxygen bundle, or the Oxygen installation with the Photon bundle.
For anyone that wants to test this, please do it before any build triggered by commits being pushed. This only happens when the latest builds of both Oxygen and Photon are the time triggered builds done at 21:43.
/Peter Cigéhn
From: mdt-papyrus.dev-bounces@eclips
e.org [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx ] On Behalf Of Ed Willink
Sent: den 10 november 2017 13:27
To: mdt-papyrus.dev@xxxxxxxxxxx
Subject: Re: [mdt-papyrus.dev] Colliding version numbers between Oxygen and Photon?
Hi
If you are using Oxygen, you must not have a Photon repo on your list of available sites. No Photon and the problem should go away. With a Photon repo, you should not get any Oxygen installs.
Different start times would avoid one source of debugging confusion but probably not solve the problem.
Papyrus releng appears to have a bug in churning version qualifiers. With Buckminster, unchanged plugins could preserve their version by comparison with a previous repo. With Tycho, qualifiers can be based on the transitively last GIT commit time. See https://wiki.eclipse.org/Tycho
/Reproducible_Version_Qualifie rs The earlier bug makes it hards to tell whether Papyrus has a further bug through failure to apply an at least +0.0.100 advance to the post release 'unchanged' bundles. The same major/minor/maintenance version should never appear from two different development streams. See https://wiki.eclipse.org/Versi
on_Numbering Regards
Ed Willink
On 10/11/2017 11:54, Cigehn Peter wrote:
Hi,
Today I bumped into exactly the same issue once again, and I ended up with a non-working installation for the Oxygen track (since it incorrectly got the Photon version). When looking a bit closer I can see that the time triggered build for both Oxygen as well as Photon happens at exactly 21:43. Could someone be so kind to at least make sure that the time triggered (periodic) builds at least happens at different times to avoid this version number conflict?
https://hudson.eclipse.org/pap
yrus/job/Papyrus-Master/config ure https://hudson.eclipse.org/pap
yrus/job/Papyrus-Oxygen/config ure
This would at least reduce the risk of conflicts like this.
/Peter Cigéhn
From: mdt-papyrus.dev-bounces@eclips
e.org [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx ] On Behalf Of Cigehn Peter
Sent: den 27 oktober 2017 16:38
To: mdt-papyrus.dev@xxxxxxxxxxx
Subject: [mdt-papyrus.dev] Colliding version numbers between Oxygen and Photon?
Hi,
I have had ”random” issues with my installations of nightly builds for Papyrus Oxygen and Papyrus Photon which have puzzled me for quite some time. I use an own made Oomph setup file and use the Eclipse Installer to manage my installations of nightly builds. And thus I also use a shared p2 bundle pool.
The problem is that from time to time, the UML architecture context gets “lost”, i.e. when trying to create a new model the list of available architecture contexts is empty. Apart from that it also impacts other things like empty palettes in the diagram editors and so on.
When checking a bit closer with the OSGi console I can see the following (in my Oxygen installation):
osgi> lb -s org.eclipse.papyrus.uml.archit
ecture START LEVEL 6
ID|State |Level|Symbolic name
522|Installed | 4|org.eclipse.papyrus.uml.arch
itecture (1.1.0.201710270144)
The bundle is installed but not started. When trying to start it, the following happens:
osgi> start 522
gogo: BundleException: Could not resolve module: org.eclipse.papyrus.uml.archit
ecture [522] Unresolved requirement: Require-Bundle: org.eclipse.papyrus.uml.diagra
m.sequence; bundle-version="[5.0.0,6.0.0)"
This is kind of strange, since this bundle is only 4.0.0
osgi> lb -s org.eclipse.papyrus.uml.diagra
m.sequence START LEVEL 6
ID|State |Level|Symbolic name
549|Active | 4|org.eclipse.papyrus.uml.diag
ram.sequence (4.0.0.201710270144)
When checking a bit closer, it turns out that, for the latest nightly builds of both Papyrus Oxygen and Papyrus Photon, the version, including the qualifier, is identical for this plugin, i.e. they both have the version 1.1.0 with the same time stamp 201710270144.
This in its turn I guess causes the shared p2 bundle pool to become a bit confused, and it manages to install the Photon version of the org.eclipse.papyrus.uml.archit
ecture bundle into the Oxygen installation, thus causing the bundle to never load to the unresolved requirement.
When analyzing the bundle pool with the Eclipse Installer, one can indeed see the same version of the bundle being installed in both my Oxygen and my Photon installation:
I am not sure why the time stamps are identical, i.e. both 201710270144. Is a time triggered build that happens *exactly* the same time for both Oxygen and Photon that causes this? Most of the time the time stamps are different, when triggered by commit on its respective branch.
Should the org.eclipse.papyrus.uml.archit
ecture bundle really have version 1.1.0 for both Oxygen and Photon, when it actually have different content and different dependencies with different version ranges?
Or is this just a flaw with how the shared p2 bundle pool in the Eclipse Installer works?
/Peter Cigéhn
_______________________________________________ mdt-papyrus.dev mailing listmdt-papyrus.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________ mdt-papyrus.dev mailing listmdt-papyrus.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
--
Camille Letavernier
Senior Software Engineer EclipseSource FrancePhone: +33 1 85 41 09 21Hangouts: cletavernier@xxxxxxxxxxxxxxxxxEclipseSource France SASPalaiseau-Entreprises7 rue de la Croix Martre91120 PalaiseauGeneral Manager: Remi SchnekenburgerRegistered Office: 7 rue de la Croix Martre, 91120 Palaiseau, FranceCommercial Register 824 977 516 R.C.S. EVRY
_______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/ mailman/listinfo/mdt-papyrus. dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus. dev
