Due: URL to your repository by Friday, May 20
This release of your system builds on the beta release: now all major functionality should be present, and a user should be able to perform any of the tasks that are part of your requirements.
It is permissible for some bugs to remain in your product, but they should not seriously affect usability and must be documented in your bug tracker, which should be up to date with the current status of your implementation. (One common place that functionality may be missing in a feature-complete release is in error-handling. But do strive to get even that working properly for this release.)
The user documentation should be complete or nearly complete.
All requirements and design information should be up to date; this includes your SRS, SDS, UML diagrams, etc. The staff must be able to find both the originally-submitted and the current versions of your documents. You must clearly indicate (in a manner that you consider appropriate) any changes since the beta release.
You will be evaluated on the thoroughness of your tests, which should be in a solid and essentially complete state. Furthermore, it must be apparent to someone reading them that they are sufficiently complete. That is, like any other part of your code, they must be comprehensible. In addition to (not instead of) their documentation, you must document how to run a coverage tool as one metric of their quality, and must include the outcome of a recent execution of the coverage tool on your code.
The code should be well-written and well-documented, use good style, and be easy for a new developer to understand and modify.
Hint: We strongly recommend that before any public release (namely, the weekly milestones), you manually test any instructions that appear in your documentation. This is crucial in detecting any problems in what you have written down. If the instructions are easy to follow, this will not be a burdensome task.