-
Notifications
You must be signed in to change notification settings - Fork 295
Development Process
We encourage code development and contribution. This page describes the process for g2core development and code contribution. We use this ourselves to keep a better record of all the changes, and keep the repo cleaner.
See also: Getting Started with g2core Development
We do development by features branches and pull requests (PRs). A feature is any code change that adds new capability of fixes a bug. Feature branches should be separate, i.e. avoid multiple new functionality in a single feature. The basic process steps are:
- Open an Issue for the Feature
- Develop And Test The Feature
- Regression Test The Branch
- Pull Request
- Close the Feature
- Tag a Release
- Publish the Release and Release Notes
Here are our conventions for developing new features. Yours might be somewhat different, as sometimes you don't know if you will contribute code, so these steps may be done later, or tied directly to a PR (no new issue).
-
Open an issue for the feature. Explain the reason and function. If you are going to be developing it please let us know. Remember the issue number. You will need it to label the branch.
-
Make a development branch in your repo for that issue
- Presumably the branch is from g2/edge, but may be from elsewhere (generally not recommended)
- Name the branch dev-XXX-featurename, where XXX is the issue number from the g2 Issues
- Don't worry about build numbers during this process - this will get set in the last step (close feature)
Development:
- Whatever you do
- It can be useful to pull edge periodically and merge edge into your development branch. This will ensure that when you finally do a PR it will merge without issues.
Documentation:
- We appreciate at least some documentation for a feature that adds new capabilities. You can create a wiki page in your repo that can be ported over later. In some cases this is a modification of an existing g2 capability, so you can start there.
When you think you are ready to promote the branch you should run a full regression test using github/synthetos/tg_pytest. Obviously trap and correct and errors. All instructions are in the readme.
Generate a PR to the target branch - presumably g2/edge
- First ensure that the PR will merge into the target branch by merging current edge into it in your repo
- If the test build does not merge resolve merge conflicts in the new branch
- Do the pull request: - https://github.com/synthetos/g2/pulls
- Go to Compare and hit
compare across forks
to pull from your repo
- Go to Compare and hit
Notes:
- The PR must pass full regression testing after merge or it doesn't get pushed
- We will close the issue once the PR is accepted/ We may advance the build number as well, depending on the nature of the PR.
-
After a group of PRs are closed, and the code in
edge
is determined to be at least usable for testing, then we can tag it, which will trigger TravisCI to make a build and push the binaries to to releases page. -
The tagging process:
-
In a commit on it's own, change the define
G2CORE_FIRMWARE_BUILD
in g2core_info.h to use the format described next, with a one-sentence brief description of what's in the change. You can refer to fixed issues by the github convention of#nnn
. -
For now, tags must take the form of
XXX.nn
where XXX is currently101
andnn
is updates by 1 each tag. It is important that there not be any additional spaces or letters in the tag itself. The git tag itslef is an "annotated" and unsigned tag with the comment/description on the tag should match the comment in the code. -
For example, the code would say:
#define G2CORE_FIRMWARE_BUILD 101.01 // fixes #123, #124, and #125
and the git commit line would read:
git tag -a 101.01 -m '// fixes #123, #124, and #125'
-
-
When satisfied with the tag, push it to Origin (or whatever your target is). This will kick off the Travis build that creates the release on the releases page.
-
Once that's done, go to the release page and create / edit the release notes. This should just be a cut and paste of the latest section of the readme. but may have additional information as well.
Getting Started Pages
- Home
- What is g2core?
- Who uses g2core?
- Jerk-Controlled Motion
- Getting Started with g2core
- Connecting to g2core
- Configuring g2core
- Flashing g2core
- Troubleshooting
Reference Pages
- Gcodes
- Mcodes
- Text Mode
- JSON Communications
- GPIO Digital IO
- Alarms & Exceptions
- Power Management
- Coordinate Systems
- Status Reports
- Status Codes
- G2 Communications
- Tool Offsets and Selection
- Probing
- Feedhold, Resume, Job Kill
- Marlin Compatibility
- 9 Axis UVW Operation
- gQuintic Specs
Discussion Topics
- Roadmap
- GPIO for 1.X Releases
- Toolheads
- Raster Streaming Prototol
- g2core REST Interface
- Gcode Parsing
- G2 3DP Dialect
- Consensus Gcode
- Digital DRO
- Overview of Motion Processing
Developer Pages
- Development & Contribution
- Branching and Release - DRAFT
- Getting Started with g2core Development
- Project Structure & Motate
- Compiling G2
- OSX w/Xcode
- OSX/Linux Command Line
- Windows10 w/AtmelStudio7
- Debugging G2 on OSX
- Board and Machine Profiles
- Arduino Due Pinout
- Arduino DUE External Interfaces
- Diagnostics
- Debugging w/Motate Pins
- Development Troubleshooting
- g2core Communications
- Git Procedures
- Windows 10 / VMware 8 Issues
- Dual Endpoint USB Internals
- G2core License
- VSCode Setup
- Compatibility Axioms
- Wiki History