On 04/12/2013 Andre Fischer wrote:
I have just checked in what basically is a reimplementation of the defunct support for creating patches on and for Windows.
Thanks, another nice step forward.
0. Expected (disk) space and time requirements: Disk space: Number of languages * - Previous downloadable installation set (EXE) in ext_sources/ - The above unpacked in instsetoo_native/wntmsci12.pro - The CAB file of the above (maybe 95% of the installation set) unpacked - The installation set and downloadable installation set of the current release - A copy of the above, arranged so that msimsp.exe can process it. - The MSP patch, about 10% of the downloadable installation set. I did not measure it but I would estimate the total to be around 500 MB
So for (say) 40 languages we would be around 20 GBytes and 20 hours. It seems that the above can be scripted and cached, but indeed this is an extra burden for the release manager.
2. Store information about the new release for when we will be creating patches when doing the next (future) release.
So basically the system is assuming that OpenOffice release numbers always increase over time, right? I mean, if 4.1.0 is released (and the patch created for 4.0.1->4.1.0) then no 4.0.2 will be released after it (or anyway the patches won't support it, since this would very quickly become absurdly complex). So basically patches assume that we only have one development line active at any given moment, or to be more precise: once 4.1.0 is released (and a patch 4.0.1->4.1.0 with it), it becomes the reference for new patches and further (if any) 4.0.x releases are not supported by this mechanism.
Regards, Andrea. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
