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