Development Workflow

Branch Conventions

Only time-critical bug fixes or possibly trivial doc changes go directly into the master branch.

Versions

Vim Devicons uses, at least as well as it can, semantic versioning.

Each release will have a branch and corresponding tag:

• branch MAJOR.MINOR.PATCH, e.g. 0.5.3
• tag vMAJOR.MINOR.PATCH v0.5.3

Automated Testing

todo

Issues

New release workflow

• pull latest master branch
• create new versioned branch
  • "MAJOR.MINOR.PATCH"
  • e.g. 0.5.3
• merge any PRs that go in the milestone
• commit any general issue fixes/updates that go in the milestone
• update the readme if applicable
• update the changelog
  • create new list item for the release
  • create new list items for each new merged PR, fix, update, etc
    • for PRs make sure to add @ for attribution to person who made the PR
    • prefix an appropriate verb in past tense for each (Updated, Added, Fixed, Improved, Changed)
• update internal version references in all .vim files that have them
• regenerate the vim doc automatically with html2vimdoc
• e.g.

cd ~
html2vimdoc/bin/python ./vim-tools/html2vimdoc.py ~/projects/vim-devicons/readme.md > ~/projects/vim-devicons/doc/webdevicons.txt
cd ~/projects/vim-devicons/
# for now do some basic search and replace to prevent issues with special characters:
sed -i 's/✅//' doc/webdevicons.txt

• push the new branch
  • git push -u origin <new_branch_name>
• merge to master
• create tag
  • "vMAJOR.MINOR.PATCH"
  • i.e. same as branch name but with prefixed with a 'v'
  • e.g. git tag 0.5.3
• push latest master and tag
  • git push origin master
  • git push --tags
• add new release on GitHub
  • basically copy and paste the version changes from the changelog