On 06.12.2013 22:58, Andrea Pescetti wrote:
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.
I could drop the requirement that whole installation sets of previous
versions are present in the 'build release=t' step.
But when the patches are created then the unpacked previous installation
sets have to present. The msimsp.exe tool requires that. I could
delete the EXE version, but if you run this step a second time, you
probably don't want to download and extract them again.
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.
No, at least in theory, the patch creation is a little more flexible.
It can create patches between any two versions. The only requirements
on the release numbers (that I know of) are:
- The build id (as defined by the PRODUCTBUILDID in the Property table
of an MSI, which in turn is set from the BUILD value in
solenv/inc/minor.mk) has to increase.
- The target version (the one the patch upgrades to) should not be a
major version, ie something like 4.5->5.0 is discouraged by the
Microsoft documentation. A major version should be a full installation set.
Therefore it should be possible for us to (should the need arise) to
create patches 4.0.1 -> 4.0.2 AND also patches 4.0.1->4.1.0.
Here is how the two version numbers are specified (I call them source
and target):
- The source version is specified via the
instsetoo_native/util/openoffice.lst file via
Apache_OpenOffice
{
Settings
{
variables
{
...
PREVIOUS_VERSION 4.0.1
...
}
}
}
If that is missing, then the Perl script tries to determine the previous
version based on the target version.
- The target version is always the currently built version. The Perl
scripts that create the patches can handle a different target version.
I just have not yet added a way to explicitly specify it.
I am open for ideas to make this more usable.
-Andre
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
