> On 17 Nov 2020, at 17:24, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>
>
> It is not so much that we change the 6.0.0 release multiple times, more that 6.0.0 is not a release yet, so not final yet. CDT puts milestones in a pre-release Dir, such as those in https://download.eclipse.org/tools/cdt/builds/10.1/
aha. this also means that you have to manage the folder name, and that if you publish several times to the same folder, EPP builds will temporarily fail until you update SimRel and EPP.
No. Each build contributed to simrel gets its own folder. As I said, such as those in the link, click on the link and each milestone/contribution is in here.
my current procedure is quite simple, a Jenkins jobs builds whatever new branch it identifies, and leaves the result in folders named by the branch.
then there are two more jobs that I trigger manually:
- one to make a plug-ins pre-release, which copies the /builds/master content to /updates/v6-test/, and
- one to make the plug-ins release, which copies the /builds/master content /updates/v6/, and /releases/x.y.z/
the basic problem here seems to be that as long as folders are referred by SimRel, their content should not change.
this implies that if work to a plug-ins release is tied to an Eclipse release and multiple pre-releases are created and linked to SimRel (our current case with 6.0.0), SimRel should point to pre-releases.
we can fix this by changing the Jankins job that publishes the pre-releases to both write the result both to /updates/v6-test/ and to a new folder.
I can imagine two solutions:
- add sub-folders with the full build timestamp inside the releases, like /releases/x.y.x/yyyymmddhhmmss/
- use a separate folder like /pre-releases/x.y.z-yyyymmddhhmmss/
I don't know what the retention policy should be; if we want to preserve pre-releases too, then sub-folders below /releases/x.y.z/ are probably a good fit.
if not, we can use the /pre-releases/ folder and purge it entirely after SimRel was changed to point to the final /releases/x.y.z/.
personally I don't think we need to keep pre-releases, so I'd lean towards the second solution, but I'm open to suggestions.
70+ projects contribute to simrel, their common knowledge is in the link shared earlier giving multiple options on how to handle p2 repos. So any of the solutions are fine.
The retention policy should be milestones kept until release is complete.
The issue I have is you should not put a pre-release in a directory called release.
Thanks
Jonah
