Can anyone provide insights on the frequency at which Scratch Org Snapshots are updated and the reasons for these Snapshots changing? I'm curious to know if there's a regular schedule for updates or if it varies based on certain factors. Additionally, understanding the motivations behind Snapshot changes would be valuable information for our community. Your insights are greatly appreciated!
@Vivek Chawla pointed me here.
As an ISV (OEM flavour) we would use snapshots to hold dependencies to avoid the over 70 minute install time for those dependencies when creating scratch orgs for "extension" (typically integration) packages.
For each extension package we typically work on up to 3 branch versions, depending on the type of work being done, but 3 is usual for bug fixes: the version the bug is reported in, the latest GA version of the package and the main trunk development.
We typically maintain the same dependencies, and thus the same snapshot, for released versions (though this is not always the case). The main trunk development is where dependency versions are most likely to change, but only when absolutely necessary. We typically leave dependencies alone, to give the best spread of supported version combinations - we are, after all, essentially specifying minimum dependency versions.
So, our snapshots will in themselves rarely change, with new ones created when we release a new extension package version with new dependencies.
For me, it is important that snapshots live as long as we need them, not just 30 days as defined in the release docs, and that they are managed transparently.
Were I doing this, I would want a switch on the scratch org creation that says "use or create a snapshot" and have another command in the build process that marks when to generate the snapshot if required.
I would keep scratch org snapshots alive like sandboxes, such that they disappear after n months of disuse AND with a LRU policy against a cap on numbers. 5 is not enough though - as mentioned, we will need separate quantities per "extension" package. 5 per package would suffice, allowing for up to 3 common bug fixing versions, the latest GA and the development trunk.
My goal would be to ensure that scratch org creation/snapshot selection is transparent to the scripting and for the only difference to then be the real-time delay (short when using a snapshot, long when building the scratch org, installing dependencies and creating the snapshot).
This might require a special command pair that switches the CLI into a different mode (or could be something else entirely). The snapshot to use/create could be identified via some hash of the installed/deployed metadata.
