Release process: Difference between revisions
From FreeMind
Jump to navigationJump to search
Line 10: | Line 10: | ||
# Every developer is allowed to 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. 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. The release has to be published in the main download package. | # Every developer is allowed to 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. 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. The release has to be published in the main download package. | ||
== | == Gate of beta version == | ||
There shall be mandatory smoke tests before a release of a beta version. | There shall be mandatory smoke tests before a release of a beta version. |
Revision as of 06:22, 27 June 2007
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.
The release process
- Every developer is allowed to produce a alpha version any time he wants. No tests are mandatory for it. The alpha versions are published on the FreeMind web site. Creation of CVS tag is required. In order 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. The minimum release package should contain the source code (src.tg.z or src.zip)and one compiled version (bin-max.tg.z or bin-max.zip). A CVS tag may be created for each new alpha version.
- Every developer is allowed to propose release of beta version any time he wants. The beta versions are always published in the download section in package "freemind-unstable". 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.
- 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. A CVS tag should be created for each new beta version. The installer for windows, mac and debian may be omitted for beta versions or be created later without performing the smoke tests again, because the CVS tag is known.
- Every developer is allowed to propose to convert any beta version published at least one month ago to release candidate, if no critical bugs has been reported for this beta version. The code of the release candidate may contain only minimal changes against the beta version, in the other case new beta version should be released.
- Every developer is allowed to 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. 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. The release has to be published in the main download package.
Gate of beta version
There shall be mandatory smoke tests 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?
Memory profiling before RC and release
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