Replies: 2 comments
-
Hi @zoli13. Taking a step back on this specific question, the fixed version binaries are essentially just a point-in-time snapshot of the evergreen binaries. We don't have any current plans to try to configure fixed version and deviate from evergreen in any way, otherwise it gets pretty hard to maintain compatibility. The way a particular file is used is not guaranteed to persist across versions (i.e. whatever we say about the .pak may not hold true for the future) and modifying those binaries is not something that is considered as supported. That said, evergreen is a much better option if disk space is an important factor, and if you are set on using fixed version 104, we can follow up internally to see what are the implications of deleting those files on 104. |
Beta Was this translation helpful? Give feedback.
-
Hi liminzhu , I know, but our customers might not even have public internet connection. Even if so, evergreen version can update itself (according to my knowledge), but our app won't be updated, so by time, some incompatibility might occur in the future? So we chose the fixed "snapshot". It can be well tested also. It's not that important to investigate in 104 specifically, just thought it had some general non-version-specific behavior, what you could explain here. |
Beta Was this translation helpful? Give feedback.
-
We use fixed version runtime (104.0.1293.54), and the Locales folder is 73MB, has 84 .pak files.
This is quite huge, would be great to cleanup.
Question, how/when are these files used?
Considering we don't know the customer's locale, can we force to keep and use only one (e.g.: "en-US"), regardless of customer's system locale?
I tried that: deleted all PAK files (I expected some "built-in" default English will be used), but it just crashed.
Beta Was this translation helpful? Give feedback.
All reactions