Deploying code to the server

1. Update the next version number to develop branch directly:

   1. Go to build.sbt and increment the version number. I usually follow a set of guidelines for updating the version number. See guidelines after these steps. When in doubt, consult with the team.

   2. Add a new evolutions file to the conf/evolutions/default directory. The Ups in the new file should be

      INSERT INTO version VALUES ('4.3.8', now(), '<optional_description>');, and the Downs should be

      DELETE FROM version WHERE version_id = '4.3.8';

   3. Push with the following commit message: "<old_version_number> -> <new_version_number>" e.g. "4.3.7 -> 4.3.8"

2. The changes will be automatically pushed to the sidewalk-test server within the next hour or so. Test all the changes once on the test server.
3. Create a pull request from develop to master named v<new_version number> e.g. v4.3.8. This would be merged into master. I always create this PR the day I will push the changes to the server. This way I know when the new version was deployed.
   1. In the description, I list the changes that were done since the last version.
   2. See example - https://github.com/ProjectSidewalk/SidewalkWebpage/pull/1175 Both issue numbers and their PR numbers are mentioned.
   3. To know which changes were merged since the last update, I usually list the closed PRs sorted by “recently updated”. Sometimes it includes PRs that were from previous versions if they were updated in any way. Github also shows how long ago the PR was merged, so make sure to check that for every PR you reference.
4. Merge it with the master
   1. This will automatically trigger a code pull and container rebuild on sidewalk.cs.washington.edu. It should take a few minutes for the rebuild to occur, but you should then be able to see the new code there.
5. Once you see the updated code on the production server, create a new release.
   1. Use "v4.3.8" as the tag version and release title.
   2. Use the master branch as the target branch.
   3. Copy the description of your PR for this version into the description for this release.

Versioning Guidelines:

(Adapted from http://semver.org/)

Versions are in this form: X.Y.Z (Major.Minor.Patch)

Patch (Z) is updated when there are bug fixes Minor (Y) is updated for backward compatible changes. We update this when we add some enhancement to our features (e.g. minor additions to the onboarding instructions) Major (X) is updated when there are backwards incompatible changes. We update this part when we completely revamp a specific feature or add new features. A new landing page could be one example, addition of new visualizations could be another.