Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [embed-cdt-dev] Embedded CDT v6.0.0 major release preview


> 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.

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.


regards,

Liviu



Back to the top