On Sun, 4 Mar 2018, Chris Cunningham wrote:
On Mon, Feb 19, 2018 at 8:34 AM, Bert Freudenberg bert@freudenbergs.de wrote: On 18 February 2018 at 23:30, Chris Cunningham cunningham.cb@gmail.com wrote: Based on feedback from last round of asking for feedback (and a few spelling fixes, too). I have removed discussion about the method movement, since it *should* just work; and I've put pointers in for new topic on renaming classes.
... * When you need to ensure a preamble or postscript script is run for a package, include the version in a new configuration (otherwise it could be skipped - trunk only loads the latest version of a package if specific versions are not called out in the update configuration)
Not quite. If you need a preamble/postscript to run again, it needs to be modified (just add a new line or space).
These scripts should be coded to be safely run multiple times. That means, each part of the script should check if it is necessary to run,
That would only be possible if you were able to predict the future. The condition the script checks may become true again later.
then execute the needed system massaging. Newer additions should go on the bottom. It's not usually needed to remove older parts of the script when they are properly protected by these guards. But after some time passes (let's say after a new system release) then cleaning up these scripts is a good idea.
I wrote several of these scripts in the past, and based on my experience, I think it's perfectly fine not to make them runnable multiple times, and it's also perfectly fine to delete those which have been executed. This is because of the nature of these scripts, you only want to run them once. If you want to run something multiple times, you'll create a method instead of using these scripts.
A modified script *will* be run at the next update even if not mentioned explicitly in a config map. That is because as the last step of updating, the updater builds an implicit config map from all the latest packages in the default repository, and loads it.
I didn't get across what I wanted here. The idea/concern was that if the script was added since the last update configuration, and is being changed again without the package being mentioned in the next update configuration, then one of the previous versions with the previous script needs to be specifically mentioned in an update configuration. Otherwise folks updating from an older version of the image will skip all versions
These scripts must work the first time, you simply don't change them again. If you have to change them, then the update stream is already in a broken state. Fixing it from that point will involve things you wouldn't do normally: delete/reupload the package/config map, etc.
How to check if the scripts work? 0. prepare your package versions 1. get a fresh image 2. load them one-by-one in the order the update process would 3. back to 0 if there's an error
This of course won't work if you want to change the update process itself, which is close to impossible right now. I think forking a process to load each .mcm would help with that.
Sometimes it's worth to think about external packages too: just because something won't affect a pure Trunk image, it may cause problems if there are other packages loaded into your image.
Levente
of the package with the older script.
Of course, that isn't even close to what I wrote, was it?
So, how about that mention of the scripts be removed from here. Somehow the usage (what you said above) is added to the script editor for clarity of the user (and maybe documented in the Wiki for good measure as well). And the release instructions mentions building a specific config map for the release (?) that ensures all past scripts have been run, so it is safe to clear them out if desired.
-cbc