Deploying code to the server - ProjectSidewalk/SidewalkWebpage GitHub Wiki

  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 ('<new-version-number>', now(), '<optional-description>');, and the Downs should be

      DELETE FROM version WHERE version_id = '<new-version-number>';

    3. Push with the following commit message: " - " e.g. "4.3.7 - 4.3.8"

  2. The changes will be automatically pushed to the sidewalk-test server within the ~15 minutes. Test all the changes once on the test server.
  3. Create a pull request from develop to master named v e.g. v4.3.8.
    1. In the description, I list the changes that were done since the last version. I try to keep them friendly to non technical users. I list the more user-facing changes near the top, bolding 1 or 2 of the biggest highlights, and list them in decreasing order of importance to end users.
    2. See example - https://github.com/ProjectSidewalk/SidewalkWebpage/pull/4188 Both issue numbers and their PR numbers are mentioned so that it's easy to find our way back to them in the future.
    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
  5. Copy the release notes you added to that PR, and use them to create a new release. The new tag is what triggers the build on the prod server.
    1. Use "v" 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.