Versioning / Branches / Releases

[ClemensElflein]

At this point it would be nice to think about release + versioning, since it's not optimal right now.

Current State
Currently, I'm just pushing updates and we're using the latest development state. This is fine for now, because I try to only push things that are working, but in the future it might be nice to have a "stable" release.

Goal
Since the OpenMower is basically two components, the hardware and the software, it would be nice to have a versioning system which shows which hardware version works with which software version.

Also it would also be nice to provide a packaged bundle of hardware (BOM, Gerbers,...) and software (precompiled image).

Progress
Vermut on my Discord is working on streamlining the KiCAD releases and jakub is working on streamlining software releases.

Currently the idea for hardware is to have a GitHub action which checks DRC, packs gerbers, generates iBOM, etc. This solves the problem of people just wanting to get Gerbers + BOM to order the PCBs without getting into KiCAD. This also prevents me from forgetting to generate the artifacts.

For the software the idea is to have a GitHub action to pack a docker image. This allows people to quickly get the software, they won't need to compile + it's easy to upgrade.

This issue is meant for discussion about where to go from here basically.

[ClemensElflein]

• jakub and I are thinking about removing the link between the repos and only having the final stable software image here. If someone wants to develop, they should get the other repo for the sources.

[rfvermut]

DRC/ERC checks can be per-commit, CI style. And everything like linters, code-style, compilation attempts.

And artifacts can be published/generated per tag.

[ClemensElflein]

So basically as I understand it, we're doing the following:

• For the current master state, a GitHub action builds software and hardware artifacts. These should be used for development purposes / latest feature testing only and should not be considered stable.
• Since the software repo will be decoupled from this one, it will also build a Docker image for the latest master "unstable" version.
• For a stable release, we'll create a tag and the user knows the latest tag will be a stable version.

The question is: How do we get this to synchronize? I.e. each "stable" OpenMower release will probably consist of software and hardware artifacts.

Do we manually create software and hardware releases independently in the two repos and using the version number, the user can get compatible versions (i.e. all 1.x hardware versions will work with all 1.x software versions) or do we somehow synchronize the repos and pack everything together into one big (hardware + software) release bundle here?

When packing everything together and we're just doing a software release, this would probably mean that new release will copy the older versions of the hardware with a new version number on it (I don't like that, because the same exact PCB will be stamped with different versions).

So I'd go with different releases sharing a major version.

[jkaflik]

I don't have any experience with hardware release process lifecycle, however I believe hardware will have much more less frequent release process.

I believe we will have dozens of iterations on software for only one change on hardware. Additionally, there is an idea ROS stack will support more than OpenMower's mainboard. We already have @ClemensElflein 's board and @cloudn1ne 's Mowgli custom firmware for c500.

IMO we should have hardware & software with an independent release cycle. This will require us to keep some kind of "contract" alignement and think better about the breaking changes later. Sharing same major version is good idea.

[cloudn1ne]

i think it would be nice to have a stable interface (e.g ros topics, services etc) - because then software like mowgli (which is really just a ROS enabler for existing hardware) can be linked with some middleware to OM. Middleware can be maintained separately.

At least 2 ppl have that already running with forks from openmowers comms node.
As i wanted to learn about ROS i went with robot_localisation, but even that is running since 2 days with full sensor fusion (RTK GPS, onboard IMU, ext IMU, odometry) and i can send the bot around, but i will invest some time next to make it work with OM - e.g. do some middleware.

besides that the v4.4 mainboards should also be investigated, looks like an 8051 on there that could be made to work like mowgli.

bottom line some stable api def would be nice.

[ClemensElflein]

I agree and I'm trying my best to keep the API stable. But since it's still in development (there is not really a stable software to begin with), the API might still change. I'm sorry for the larger breaking changes, but they were necessary to simplify configuration and to support more hardware configurations.

Great work on Mowgli btw!

[cloudn1ne]

cool im gonna check out your code and will try to understand it as much as possible and then setup some kind of middleware proxy services - maybe at some point we can make adjustments to make life easy for eventual other hardware.

i have some kind of capabilities announcing schema in mind atm. if one day OM hooks into that, other hardware should be easy to support as long as it supports some minimum reqs and adheres to the ROS REP stds