Hello everybody, many people ask themselves why the last beta version was published in February and no other versions have been released afterwards. I ask myself too, and I would like to discuss it with you. Currently no process is defined and consequently no process can work.
Dear Chris, Dan and Eric, I know that you everyone is very busy. The aim of this discussion is reducing of the time each of you has to spend for producing the next release, because defining of standard makes anybody (like me) able to perform the steps once they are defined. I ask you to acknowledge the importance of these questions and to submit your answers to my proposals, so that both release cycles and amount of time spent for producing next releases can be kept minimal. I see two basic problems: 1. How the decision to release the next beta based on some CVS stand can be generally taken, and 2. What should be done in order to produce the release, who is allowed to do it and what steps and standards should be considered. I want to say that I would spend my time for producing the release, if the above questions were clarified. But nowadays I do not use the Program so intensively that I could see whether current code stand is stable enough. I also do not know, what packages should be prepared for a beta (I suppose WindowsInstaller.exe, src.tg.z, bin-max.zip and the Mac - package, but I currently do not know how to create it). Let me describe a process which I hope could be a good solution. If you accept it, it opens a way to producing the new beta versions avoiding the blocks. You are highly welcome to make your comments and suggestions. ==== The release process ==== 1. 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. 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. 2. 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. 3. 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. 4. 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. 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. ==== The mandatory smoke tests before release of a beta version ==== 1. Open the freemind documentation, check that every node is shown correctly. 2. Test creation, modification, deletion, change of geometrical position of nodes, clouds, attributes using mouse and using keyboard only. 3. Test copy&paste, cut&paste, drag&drop of nodes using mouse and using keyboard only 4. Define an attribute based filter and apply it. 5. Create a new map, test switching between the old and the new map. 6. Test export of the documentation map to HTML and to browser, check navigation in the browser. 7. What plug-ins should be explicitly tested ? What about Search / Replace / Links ? Even more items? ==== Mandatory Memory Profiling before producing a release candidate / 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 ========================================================== I am sure that defining and performing of the smoke test are necessary for insuring the quality of the published FreeMind versions. The list of the smoke tests has to be modified as our experience grows. I suppose that the lack of the smoke test and release process definition is the main reason for long development cycles of FreeMind. Best regards, Dimitry ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
