Publishing

Publishing releases

The github repositories for both the interpreter and the debugger are configured to make a new release when a new tag is pushed. This makes the upload process simple, however there are some steps to make sure the version numbers are correct before publishing.

Versioning

THIS PROJECT DOES NOT FOLLOW SEMVER Let's follow semver looking numbers but by no means do we need to respect the rules of semver, this project doesn't offer a consistent API but rather a program that operates as a professor of a course would like it to, the version numbers simply offer a way to reference what features are distributed to students.

Some examples of what number to change in a version bump are:

• Bug fixes should be bumping just the third value (patch number)
• New functionality that doesn't affect students should bump the minor version (I'm thinking grader features, debugging features)
• New plugins that offer a whole new way of doing an assignment should bump a major version

At the end of the day, sky is the limit for any of the values, if we end up on major version 2344.0.0 in under a month, so be it.

Version number syncing

This may be silly and we can abandon this idea, but I think when ever we make a release of one, we should make a release of both, and keep the version numbers in sync. The debugger and interpreter aren't inherently tied like this but it would seem to make sense to make sure that both code bases are in sync when distributed.

Interpreter

1. Make sure all the changes you want in the release are present on the master branch.
2. You'll first want to change the version number in pyproject.toml to the next version you are going to publish. (example: 0.0.0, no "v")
3. Commit that version change to the pyproject.toml file and push it
4. Tag that commit with the same version number and push the tag
   1. git tag 0.0.0
   2. git push --tags
5. That's all, github should handle the rest, below is a summary of commands github will run:

poetry build -f wheel
twine upload dist/*

NOTE: poetry build -f wheel bundles our python on creates a file: ./dist/dashmips-0.0.0-py3-none-any.whl

NOTE: twine is a python tool to upload to pypi, if you need to make a release manually you can use this

Debugger

1. Make sure all the changes you want in the release are present on the master branch.
2. You'll first want to change the version number in package.json to the next version you are going to publish. (example: 0.0.0, no "v")
3. Commit that version change to the package.json file and push it
4. Tag that commit with the same version number and push the tag
   1. git tag 0.0.0
   2. git push --tags
5. That's all, github should handle the rest, below is a summary of commands github will run:

npm run package
npm run publish

NOTE: npm run package bundles our extension on creates a file: ./dashmips-debugger-0.0.0.vsix for uploading to github, not the vscode marketplace

NOTE: npm run publish Uses the vsce program to bundle and upload our extension, it does not use the file created from npm run package