Browse Prior Art Database

Dynamic install-time change log view Disclosure Number: IPCOM000251106D
Publication Date: 2017-Oct-12
Document File: 1 page(s) / 12K

Publishing Venue

The Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 78% of the total text.

During development a text file with changes summary is being continuously updated by developers or release manager with new changes such as a feature, defect fix, deprecation note, known issues, etc. Changes are stored chronologically. The change log also contains annotations marking released versions of the application. An example of such metadata would be a line in format "[Version X.Y.Z]", for instance: "[Version: 8.2.7]". This could be entered manually or automatically in a build process. Some changes invalidates change log entries relevant for previous versions. For example, a known issue from version N has been fixed in version N+1. Such change entries can be annotated to make this relation explicit, for example with a metadata like "[Invalidates: PATTERN]", where PATTERN is a regular expression which matches description of some prior change log entry. This allows marking invalidation with only incremental updates to change log, without modifying prior content. The complete change log with annotations is included in the installer during build process. The installation flow: 1. Determine if it's a new installation or upgrade 2. If upgrade: Check version of software already installed, store it as PREVIOUS_VERSION 3. Perform the installation 4. Read change log metadata 5. If upgrade: Check if annotation with PREVIOUS_VERSION exists in the change log. If it does, discard all the changes annotated by this version or earlier. 6. For all remaining change entries look for inva...