Here’s a list of stuff that’s still open.
1. Decide if we pursue the inclusion of a single “sample” MPCNC config in Marlin upstream
If yes, let’s review Marlin/config/examples/CNC/MPCNC at v1-base-config · anttix/Marlin · GitHub and cut a PR to Marlin. The advantage of having a config there is that comments and formatting for more complex stuff e.g. JD and CNC settings will remain intact. We should also be able to also push a test that uses this config to reduce a chance of compile errors creeping into CNC code paths in the future. The disadvantage is that if we want to change the settings we should cut a PR to Marlin. We can also forget about this idea and go with 100% generated.
2. Implement version matrix
Right now the workflows only pull down bugfix-2.0.x. This needs to be extended to include at least 2.0.x and possibly dev-2.1.x as well.
3. Hone local development process
The new development process will look like this:
- Edit a script under v1-scripts/config
- Run generate-configs (or generate-build-branch if Marlin update is also involved)
- Run build-for-machine
- Rinse and repeat.
Right now there is a mandatory commit between steps 1 and 2 and a switch back to v1-machines branch between 3 and 4. This is sub-optimal for fast turnaround, there may be a better way. I’m looking into git submodules to see if there is a combination that would provide a better experience. Submodules have their own problems though.
4. Implement a release process
Github has releases and it also has a way of marking a “pre-release” so this is the functionality we should use to distinguish between releases. My current idea is that to do a release, one would push a copy to a tag: e.g. v415-rc1 and then the build process will automatically upload zips to a pre-release draft which can be reviewed, then published. Once RC-s have gone through testing, the final tree will be pushed to v415 tag. We also need a script similar to Marlin/buildroot/bin/generate_version at 2.0.x · MarlinFirmware/Marlin · GitHub that will automatically update the version number during builds.
5. Review new configs
Preliminary scripts to generate configs are at Marlin/v1-scripts/configs at v1-machines-demo · anttix/Marlin · GitHub
6. Sanity test
So far all of this stuff just compiles. Some brave soul should pull down one of the firmwares from Release unstable · anttix/Marlin · GitHub and see if it actually works. Bonus points for pointing octoprint firmware updater plugin directly to a .bin or a .hex file
I would think #1, #5, #6 and #3 are good candidates to knock out of the park next.