Contributing

For the basic rundown about how to contribute, see the CONTRIBUTING.md file before doing anything else.

The rest of this page is about extra stuff, proposals, notes, and anything that isn't really permanent or solid enough to put in that file.

Workflow Proposal 1

This is just a proposal. It is not official.

Here's my suggestion for git workflow and managing releases. I'll start from the basic fork/clone and go into more detail from there.

1. Fork the repo.
2. Clone the repo with git clone https://github.com/<yourusername>/papyrus-lang.git
3. git remote add -m master upstream https://github.com/joelday/papyrus-lang.git (add upstream as a remote and make master the default branch so git co upstream does the same as git co upstream/master). This can be configured after the fact with git remote set-head upstream master
4. For those of us with write access, use git remote set-url --push upstream https://127.1.2.3/ to set the push URL to something bogus for upstream so there's less chance of accidentally pushing to upstream/master directly.
5. Make sure that there's an issue created for the change you want to make even if it seems small.
6. git co upstream/master -b issXXX where XXX is the issue number.
7. git push -u origin issXXX to push the branch to your fork.
8. git branch issXXX -u origin/issXXX Change the upstream tracking to origin instead of upstream. THIS IS VERY IMPORTANT because tracking will default to upstream/master, and when you push your changes it will try to push them to upstream/master!
9. Do the work, make changes, check them in etc.
10. With the issXXX branch checked out, git push
11. Create pull request.
12. Integration Manager reviews/comments and/or merges if good.
13. While not ready, iterate: modify, commit, push then repeat previous step.

Workflow Proposal 2

Same thing except we use a "upstream/devel" branch which allows us to create a "insider preview" type build. This way we don't have to worry as much about how well tested things are before they're merged to the devel branch. When devel seems stable it gets merged to master.

This is like Gitflow except less formalized and less complicated.

This command could be good for generating version numbers for devel preview builds:

git describe --tags --long --abbrev=4

Which generates versions like this based on the last tag found: v2.19.1-7-gc182 where 7 is the number of commits since the last (version) tag found and c182 is the first part of the most recent commit hash.

Other

To help avoid losing focus, try to only work on one issue at a time. If working on more than one issue, create another branch such as issYYY with the other issue number.

Release Checklist

• [_] Review code in PR
• [_] Do testing
• [_] Squash merge with commit message format type: subject where type is: feat, fix, docs, style, refactor, perf, test, or chore. See Here for more info. Example: fix: kill nasty bug
• [_] Add [skip ci] to the end of the commit message only if you need to merge without a release. Example: fix: kill nasty bug but not done yet [skip ci]
• [_] Use Squash and Commit <- don't forget this