openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject [proposal] Patches on Windows
Date Tue, 22 Oct 2013 09:48:38 GMT
Hello everybody,

At the moment we provide full installation sets for every release and 
for all platforms and languages.  An installation set has a typical size 
of roughly 150MB.  The size of the actual changes is typically much 
smaller.  Using patches instead of full installation sets would 
considerably reduce the amount of data that has to be downloaded by 
users.  For new users without existing installation of OpenOffice we 
probably still need the full installation sets.

Note that such patches can only be made for minor or micro releases.  
Major releases would still be full installation sets.

I have worked in the past months on finding out how our build system has 
to be modified in order to create patch sets on Windows.  This has 
resulted in a set of conditions [1] that have to be fulfilled by the 
installation sets.  One example of a condition that we currently don't 
fulfill is that files must not be deleted in minor or micro releases.

Up to now I have taken two full installation sets and then tweaked the 
newer one until I was able to
a) successfully create an .msp patch file and
b) successfully apply it to an OpenOffice that was installed by the 
older install set.

I would now like to change the build system, especially the 
solenv/bin/ script and its modules, so that the 
installation sets it creates can be used without further changes to 
create patch sets.  I would also like to add the patch creation itself.

For this I propose and seek lazy consensus for the following changes:

1. When a new release is made, create data files that are added to our 
version control system (semi automatically) that allow us on the next 
release to check and/or enforce the conditions.

2. Before the next release is made, read the data files of the previous 
release and check and/or enforce the conditions.

3. When a new minor or micro release is made, first create the full 
installation sets, then create patches.
    Besides the data files mentioned above, this also requires access to 
the installation sets of the previous release.

4. Cleanup of the logging mechanism used by and its 
modules, so that I can better debug the existing and the new code.

Most of the proposed changes have a low impact on the current creation 
of installation sets.  They basically only add new features (collecting 
information about a release, adding it to the VCS,  reading the 
information on next release, checking conditions, creating patches).  
However, some conditions can be enforced automatically (like using the 
same uuids for components in one release and the next) and that can 
introduce regressions, ie break installation sets.  But I think the 
danger of that is not bigger than with many other new features or bug 
fixes.  I don't expect conflicts with build system changes made or 
proposed by Jan.

More details about the creation of installation sets and patches can be 
found in the Wiki [2].



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message