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
Alpha is a purely test version. Absolutely no guarantee is made on how it's going to work, keep data format of FreeMind mind maps, and the like. One alpha version may have other features and file format than another one, as each developer with source access may create his/her own Alpha version. Users of alpha are people who want to help in the development process of FreeMind by reporting bugs in early unstable versions, or who want to influence in which direction the alpha will be finetuned.
- 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
Beta is a version with known old and newly introduced bugs, with many fixes pending and possibly smaller enhancements. Maps saved from betas should ideally be readable by later versions. Thus, allocating label beta requires considerable attention.
- 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: (a) source code (src.tg.z or src.zip), (b) one compiled version (bin-max.tg.z or bin-max.zip), and (c) one browser version. The installers for Windows, Mac and Debian are optional; they may be created later without performing the smoke tests again (as the CVS tag is known).
RC
Release Candidate is a version in which there are neither errors nor changes pending that the developers would know of at the date of publishing. After RC1, packagers and translators are called to do their work for the final release. Only changes required to fix critical bugs are acceptable; those fixes should avoid changes impacting translation or packaging efforts.
- 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:
Gate of beta
There shall be mandatory smoke tests[1] before a release of a beta version.
- Open the freemind documentation, check that every node is shown correctly.
- The browser should be tested as well, the browse mode also.
- Test creation, modification, deletion, change of geometrical position of nodes, clouds, attributes using mouse and using keyboard only.
- Test copy&paste, cut&paste, drag&drop of nodes using mouse and using keyboard only
- Define an attribute based filter and apply it.
- Create a new map, test switching between the old and the new map.
- Test export of the documentation map to HTML and to browser, check navigation in the browser.
- 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.
- I would also create/encrypt/decrypt an encrypted node.
- 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!?).
- What plug-ins should be explicitly tested ? What about Search / Replace / Links ? Even more items?
- File mode. In a cursory and cheap way, test whether the file mode is still working.
Gate of RC and release
Memory profiling
There shall be memory profiling before producing a release candidate and/or release.
- No map objects may remain in memory after closing a map (the test should be performed with the documentation map.
- No child NodeViews / AttributeViews / MainViews may remain in memory after folding a node.
- No NodeViews / AttributeViews / MainViews may remain in memory after deleting a node.
