Release Checklist

In this document, we give you a set of things to check before handing out your final project. Note that this checklist is not specific to the chatsystem project and could be applied to any software project.

You should check that your project fulfills all items before handing out the final project, at the end of the semester. You may want to keep them in mind as guidelines during project development.

Checklist

• Your repository has the metadata.yml file, up to date with your names and addresses (otherwise, we can't identify you, and you won't get a grade)
• The repository has a README file containing:
  • A few lines describing the nature and goals of the project
  • Instructions on how to compile and run the program from the source code
• The project can be compiled and executed without manual installation of dependencies.

This implies that all dependencies should be declared in the Maven configuration file. It is acceptable to have a few well-identified commands to execute, such as to initialize a database.

• Tests pass (implicitly, there should be tests).

An excellent way to ensure the above elements (compilation and tests working on machines other than your own) is to set up continuous integration. For example, you can use GitHub Actions (see an example configuration here: GitHub Actions Example). Note that your tests must be runnable on machines other than yours (even if it requires some initial setup). If another developer joins the project, they should be able to run the tests.

• The Git repository is clean.
  • No compilation artifacts in the repository (e.g., .class files).
  • No configuration files (.idea, .project) in the repository.
  • The .gitignore file is comprehensive (e.g., it prevents the addition of the mentioned files above).
  • Commits are of reasonable size with meaningful messages.

In general, you should be able to justify the presence of any file in your Git repository. There should normally be no files that are automatically generated from other files in the repository. Similarly, there should be no files specific to your machine/IDE.

• The code is structured into independent packages, organized in layers (e.g., the network layer should not have knowledge or access to the user interface or the database).
• Your code is reliable.
  • Errors are handled properly: The decision (1) to ignore an error, (2) to simply display it, or (3) to stop processing and return the error is justified.
  • Your thread management is correct: no deadlocks, protection against concurrent access.