### ## ### ## # ##### ## ## ## ## #### ###
## ## ##### ## ## ## ## #####
## ## ## ## ## ## ##### ## ####
__ __ \ \ / / \ \_/ / \ / | | |_|
#### # # # # # # ####
IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now. Visit Preferences to set your user name Summary of change: after a discussion on IRC a few guys agrees that we need to improve the testing of firmware and handle releases in a better way. We have a documented release system in firmware_revision.h, which basically is split into three decimal numbers * Major version (currently 1) ** This is rarely incremented, requires a major rewrite and resign of code * Minor version (currently 0) ** This should be incremented as soon as a firmware update changes config variables and affects tuning software * Build version (currently 29ish) ** This is currently the only number increased, but should only be used for small updates that does not affect tuning part. For this system to work, I think we should assign a testing team and release executives, who can flag that a version is stable and ready for the users. This guy is preferrably not directly involved with programming, but of course cooperates on a close level. Any suggestions for test plan and possible candidates for a team leader / release executive are welcome on this page. --- '''Possible candidates for the executive post''' * ... --- '''People willing to join the testing team, and devote some time to perform the future test plan for each release''' --- '''Test plan proposal''' Optional: Add document to category: Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.