Build processes

Versioning

The version number of SM-VSiX consists of four parts according to the following scheme <major>.<minor>.<issue>.<revision>.

Major version

It is an integer greater or equal to zero. Increasing when a new major release is published (i.e., when changes of develop branch are propagated to master branch).

Minor version

It is an integer greater or equal to zero. Increasing when a new feature or fix is merged into the current develop branch.

Issue number

It is an integer greater or equal to zero. It always equals to a number of an existing issue (either open or closed) or it is zero if there is no relevant issue.

Revision number

It is an integer greater or equal to zero. Increasing when a new version of the current feature branch is shipped to testing.

Branches

master branch

Contains the current stable version of SM-VSiX. Just the lead developer allowed to push changes.

release branch

Intermediate branch used to mitigate changes from develop to master branch. Just the lead developer allowed to push changes. Just the lead developer allowed to push changes.

develop branch

Contains the current development version (which does not contain incomplete features). All developers allowed to push changes.

feature branch

Its the common name for several branches, named according to the following scheme feature/<username>/<issue>/<title>. The <username> will be the ID of the user who is responsible to solve the related issue. All developers allowed to push changes, but only <username> allowed and obligated to merge it into the develop branch.

Scenarios

Development

Begin a new feature development

Your current branch is the develop branch.

1. If there is not an issue describing the new feature create one.
2. Move the issue to ~doing column.
3. Create a new feature branch with your user name as the responsible developer and the issue number.
4. Begin implementing the new feature.

Finish a new feature implementation

Your current branch is a feature branch. <version> note the whole version number.

1. Try the new feature and if it not works, fix it.
2. Clean up your source code.
3. Write or expand the relevant section in the documentation which describes how to use the new feature.
4. Commit your changes and push your feature branch.
5. Increase the <revision> number by 1.
6. Set <issue> number to the current feature-issue.
7. Build a new binary version of SM-VSiX and name it according to the following scheme sm-vsix_<version>.vsix
8. Build a new PDF file from the documentation and name it according to the following scheme ug_sm-vsix_<version>.pdf
9. Mark the current commit on the feature branch with the tag V<version> (and push it).
10. Attach the binary and the PDF file to the release associated with the tag.
11. Insert the URL to the release into the related issue and the id of relevant sections of the documentation as a comment.
12. Move the related issue into the ~"to test" column.

Fixing new features

1. Choose at least one issue labeled ~bug which is related to your feature located in the ~"to do" column. (The description of the issue will specify the version.)
2. For each, all related issue labeled ~bug
   1. Move the bug-issue to ~doing column.
   2. Implement the fix.
   3. Goto Finish a new feature implementation
3. Goto Finish new feature development

Finish new feature development

1. If related feature-issue is in not ~"to publish" column, wait.
2. If there is any related issue labeled ~bug, goto Fixing new features
3. Pull the develop branch.
4. Merge your feature branch into develop branch with no-commit option.
5. Resolve any problems.
6. Try the new feature and if it not works, fix it.
7. Clean up your source code.
8. Increase the <minor> version by 1.
9. Reset <issue> and <revision> number to 0.
10. Commit your changes (conclude your merge).
11. Push the develop branch.
12. Remove both local and remote feature branch.
13. Close your feature-issue.