Release process

This page describes a proccess of creation a FreeMind release and the minimum amount of corresponding tests. Because of important role of this page for the FreeMind team, it is protected. Use the discussion page for making your comments and proposing improvements.

Alpha

• Authorization: Each developer may produce an alpha version any time he wants.
• Mandatory tests: None.
• Place of publishing: The FreeMind web space.
• CVS tags: A CVS tag shall be created. A CVS tag may be created for each new alpha version.
• Minimum release package: (a) Source code (src.tg.z or src.zip), (b) one compiled version (bin-max.tg.z or bin-max.zip).
• Various: To reduce the amount of the used disk space, only one alpha version per developer is allowed to be offered at the same time; the old versions should be deleted before publishing the new one.

Beta

• Authorization: Each developer may propose a release of beta version any time he wants. If no other developer reports significant bugs or objections within a week, the developer makes smoke tests defined below, creates a CVS tag, prepares and uploads the release files and writes messages in Forum "Open discussion" and FreeMind Wiki main page.
• Mandatory tests: See below.
• Place of publishing: Package freemind-unstable of download section.
• CVS tags: A CVS tag should be created for each new beta version.
• Minimum release package: The minimum release package should contain the source code (src.tg.z or src.zip), one compiled version (bin-max.tg.z or bin-max.zip) and one browser version. The installers for Windows, Mac and Debian are optional. They may be created later without performing the smoke tests again. (Because the CVS tag is known.)

RC

• Authorization: Each developer may propose to convert any beta version published at least one month ago to release candidate, if no critical bugs have been reported for this beta version.
• Mandatory tests: See below.
• Place of publishing: Package freemind-unstable of download section.
• Various: The code of the release candidate may contain only minimal changes against the beta version; new beta version should be released otherwise.

Release

• Authorization: Each developer may propose to convert any release candidate published at least one month ago to release, if no critical bugs has been reported for this release candidate.
• Mandatory tests: See below.
• Place of publishing: Main download package.
• Various: Translations and packages are requested from the owners just after RC1, asking them to try to be finished within one month. The FreeMind documentation mind map should be updated to containg a description of all new features. The Wiki should be updated too.

Gate of beta

There shall be mandatory smoke tests before a release of a beta version.

1. Open the freemind documentation, check that every node is shown correctly.
2. The browser should be tested as well, the browse mode also.
3. Test creation, modification, deletion, change of geometrical position of nodes, clouds, attributes using mouse and using keyboard only.
4. Test copy&paste, cut&paste, drag&drop of nodes using mouse and using keyboard only
5. Define an attribute based filter and apply it.
6. Create a new map, test switching between the old and the new map.
7. Test export of the documentation map to HTML and to browser, check navigation in the browser.
8. We should have one test map for each version, and the new version must be able to open the map from the nth and nth-1 version and save both as nth version.
9. I would also create/encrypt/decrypt an encrypted node.
10. A good and easy test might be also: open the test map, don't modify anything, save as, compare files (normally, there shouldn't be any difference, or!?).
11. What plug-ins should be explicitly tested ? What about Search / Replace / Links ? Even more items?

Gate of RC and release

Memory profiling

There shall be memory profiling before producing a release candidate and/or release.

1. No map objects may remain in memory after closing a map (the test should be performed with the documentation map.
2. No child NodeViews / AttributeViews / MainViews may remain in memory after folding a node.
3. No NodeViews / AttributeViews / MainViews may remain in memory after deleting a node.