The default startup menu is a frameset, that displays information dependent on the version:

• In versions 4.25 and later, the frameset looks like this:

  • Top frame shows a list of "active" configurations, e.g. configurations that are connected to a database. (obviously this list will be empty after initial installation). In the top left corner of the frame, you will find a link called "Configurations". Clicking this link will open the Administration Module, that may be used to administer configurations and databases.

  • The bottom frames shows various documents distrubuted with the framework using TOPICA Explorer.

    • The bottom left frame show a "tree" of releases and links to documents (ReleaseNotes, DevelopmentLog, etc.) related to the respective releases.

    • The bottom right frame shows the the document selected in the left frame - initially, this (right) frame shows DevelopmentLog for the latest release.

• In versions 4.24 and earlier, the frameset looks like this:

  • Left top frame shows links to various documentation related documents.

  • Left bottom frame shows a list of configurations (whether they are "active" or not).

  • Right frame shows the the document selected in the left frame - initially, this (right) frame shows DevelopmentLog for the latest release.

Note
The documents that are displayed in the startup menu (ReleaseNotes, DevelopmentLog, etc.) are currently in danish language!

This is a document that is updated by framework developers as changes are made to the TOPICA framework.

This provides a chronological overview showing what changes have been made when - and in which builds.

This is a document that is updated by framework developers as changes are made to the TOPICA framework.

This provides a feature by feature overview of changes between each major release version.

Important
Readers should pay particular attention to any description of incompatibilites. These will be listed at the top of the document, and highlighted with a yellow background. Also, reading (and understanding) ReleaseNotes is essential, before updateting to a new version.

At first glance it might seem that the DevelopmentLog and ReleaseNotes documents contain the same information. Why are there two different documents?

• User

  • As a user of the TOPICA framework (configurator or application developer), you will sometimes need to use new versions of TOPICA - i.e. you will need to update to new version.

  • In these situations, you will need to know what has changed between one released major version and the next (e.g. between version 4.29 and 4.30). This will be described in the ReleaseNotes document - in sufficient detail to make is possible for example to make use of new features (how to configure new features, any incompatibilities that should be considerd, etc.).

    Important
    It is possible to update to a version several version numbers newer. E.g. it is possible to have an evronment running TOPICA version 4.25 and update this environment to TOPICA version 4.30. In this case you must read ALL the relevant ReleaseNotes, e.g. those from versions 4.26, 4.27, 4.28, 4.29, and 4.30),

• Tester / framework developer

  • As a tester/developer of the TOPICA framework, you will need more detailed information on how (in what stages) a new version is being developed. If for example you are testing beta versions of a new release, you will need to know which new features and bugfixes are implemented in each beta version.

  • Changes that are directly related to issues registrated in systems for bug fixes, change orders, etc. should be identified with references to these systems.

  • Say for example that a new release should fix 3 bugs and implement 2 new features. These changes will not be implemented in one build, but in the course of for example 3 beta versions. When testing a particular beta version, you should consult the DevelopmentLog to see, which bug fixes / new features are implemented in the particular beta vesion, you are testing.

  • The DevelopmentLog is also useful as a log (surprise!) for the framework developer to keep track of what changes have been made - and maybe how (without going into details).

In summary:

• One new feature should be described once in ReleaseNotes, but there might have been done work on the new feature in several different builds (so it may be mentioned several times in DevelopmentLog).

• A new feature should be described in necessary details in ReleaseNotes. Mentions of implementations of this feature in DevelopmentLog should NOT repeat those details - in stead there should be a reference (= hyperlink) to the relevant section of ReleaseNotes.