[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[qvto-dev] New release methodology
|
Hi
The prevailing practice is for the final RC release to be built in
"milestones" and manually migrated during the quiet week to "releases"
or copied from Sxxxxx to Rxxxx. The release is only visible by explicit
fully qualified access until the GA instant. As part of the migration,
"vi" was used to manually edit "artifacts.jar" to inject p2.mirrorsURL
and p2.statsURL properties.
The above actions were tedious, a bit error prone, and are no longer
possible following the increased restrictions on the remote shell access
to build.eclipse.org.
Therefore I propose to augment the current N/I/S nightly/interim/stable
builds by a new R release build (using the stable target platform) that
promotes directly to the "releases" / Rxxxx and exploits Tycho's ability
to inject p2.mirrorsURL and p2.statsURL properties.
+ most of the manual activities are eliminated
- the final release is a fresh "R" rather than the renamed "S" build
contributed to SimRel
- scripts need revision / testing
- the new release may not be fully hidden until GA
The hazard of promoting a bad "R" build is small, since if the build job
fails, the promote job does not run. QVTo builds are unfortunately
intermittent [1] so the "R" build job may fail. So 10% of the time we
have to run it again.
The SimRel divergence can be reduced by contributing the final RC at +2
and then towards the end of the final +3 day changing from the "S" to
"R" contribution. This will ensure that SimRel has exactly the release
rather than the unedited milestone as at present. If a last minute fix
is required we will just have to do at least an "a" release and perhaps
an "RC2a" release as well to practice; not that different.
Most of the script revisions have been tested using a local build, but
the final promote to releases can only be done live. Please bring any
anomalies to my attention.
The current hiding technique should still work for the download ZIP. It
may be possible to defer visibility of the P2 repos by deferring the
update of latest and releases composite repos till GA. However since
QVTo is not tightly coupled to platform releases and since EMF and
Classic OCL are pretty stable, and since EMF no longer observes the GA
hiding policy, I am not sure that it is worth the effort to stop users
seeing the next QVTo as an update a week early.
QVTo is the least likely to need an RC2 of the {OCL, QVTd, QVTo) trio
that I releng. For 2019-09, I propose to skip QVTo RC2 and go direct for
the release to give more time to accommodate any accidents.
Regards
Ed Willink
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526641
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
