New workflow for firmware releases

Before starting development on v0.7, I would like to adapt an improved workflow that is more suitable for a public (Github) repository.

What I’m thinking of doing:

  • Bugs are already tracked as Github Issues, do the same for feature requests.
  • Use one Github project for each (minor) release to track what bug fixes and feature requests are being targeted for a specific (minor) release.
  • Development for the next release happens on the main branch.
  • Development releases are made often and are versioned separately: e.g. something like er-301-dev-{build #}.
  • When ready to declare a stable (minor) release, create a branch for it. All changes and bug fixes happen there. The head of this branch tracks the most recent (patch) release to the stable version.

In the above, I’m using the following nomenclature for release numbers: v{major}.{minor}.{patch}.

Finally, how about moving all coding-related discussions to Github? Right now we have this one big thread for discussions related to the ER-301 SDK which is not really sustainable. Some discussion already happens over on Github for Pull Requests and Issues. Perhaps, the Github Discussions space should be used to field the more technical discussions and questions? Of course, publicizing one’s work, getting user-oriented feedback and so on would continue to be done here.

Your feedback is appreciated!

12 Likes

I think this is a great idea. Especially for feature requests. I know I’ve requested things in the past and honestly have no idea what thread they were made in; that wouldn’t be a problem with GitHub. And you can take advantage of GithHub’s labelling system, which is helpful for organizing requests. Will hopefully cut down on duplication and provide a single thread people can refer to, crosslinking etc. I don’t really see any drawbacks besides people who aren’t developers might not want to create yet another internet account, but in those cases I assume you’re happy to create the request/bug issue on their behalf (I think I’ve seen you do this before)

2 Likes

This is actually what I meant. I won’t expect non-coders to make GitHub accounts :wink:

2 Likes

As for branch organization, I’m not sure I follow 100%

You’re saying each minor release gets its own branch? That seems kind of strange to me. I would just keep main the latest dev version and each major release gets its own branch. So for example v6 gets its own branch, minor and patch versions get added to this same branch. v7 would have its own branch, with main being dev for that. And so on until 8.

Edit: actually in the case with v7 being the current “latest”, I would keep main for that and develop on dev branch. v7 wouldn’t be its own branch until ready to move on to 8.

The latest stable release is v0.6. That is major release 0.

1 Like

Oh, right. Ok that makes sense. Your minors are major to me :wink:

It is a bit unfortunate but v1 implies more maturity then I am comfortable with at the moment. :laughing:

3 Likes

This all makes sense to me, let master be the bleeding edge and tag/branch off the minor versions for patch work which can then be merged back into master.

Btw we also use the dsp-lua channel on Discord to discuss some dev things in real time, but any proper feature proposals ought to be on github like you say.

1 Like

Just to be clear, patches (i.e. bug fixes on a stable release branch) will indeed be merged back into master but the stable release branch sticks around and the tag for the new patched version is made on the stable release branch, not the master branch. The goal being to allow unrestricted development on the master branch without worrying about messing up anything for the stable releases and their patches.

This is the first time I will be taking such a structured approach so I just want to be sure I’m not making any stupid mistakes.

There is also the “gitflow” which has the master branch holding the production releases and development is on a separate branch.

Is this simpler?

IME git flow is over complicated for what it provides, it’s intended for large teams working on the same codebase with semi-regular releases.

I much prefer the approach you’ve already described, essentially continuous integration on master with “blessed” releases via tags/dedicated branches. This is definitely a good standard practice and I think will work well here.

Edit: I should say, the state of the art for version control during active development is the idea that master should always be releasable in its current state. Every commit to master builds the release artifacts and then it’s up to the owner to decide if it’s time to commit to a stable version.

Generally that means working on a separate branch to create a new feature to completion then making a PR to merge that into master where the build/tests/artifact will run. This is easier to follow when there’s multiple people working on the same thing and you don’t want to break their build. When it’s just you though it’s more tempting to commit directly.

2 Likes

Another goal for the workflow is that when someone other than me submits a PR that gets accepted and merged, that it is easy to get a version of the firmware that includes this contribution out in the wild for people to try without waiting for me to make an official release. So something like a nightly build on the development branch would be ideal but not necessarily an automated one.

2 Likes

well, i’m not a real coder, but moving over to Github for code discussions makes a lot of sense to me!

1 Like

This sounds backward from the way I normally work with git, which is to say that I’m used to master containing the production stable code, with branches used for development and merged back to master when considered complete and tested. But I don’t see why this approach wouldn’t work.

1 Like

Just theoretically speaking. If I were to reserve the master branch for production releases and start a develop branch, then I would need to revert or (preferably) rebase the last 27 commits. Are existing forks alright with this?

Edit: Sorry, not rebase, but reset. Something like:

git checkout master
git checkout -b develop
git push origin develop
git checkout master
git reset --hard 3c08845
git push -f origin master

In general it’s definitely best to avoid force pushing new history on master, if you go this way I’d say a revert is best. As for existing forks, I don’t think there’s anything to worry about.

I’ll force push on private branches all day long, it just feels dangerous to mess with master.

I did look into revert but balked at the idea of adding 27 new commits to master just to rewind. Is git reset really that bad? Just this once? :sweat_smile:

I see what you mean, pushing to develop first prevents losing history by accident since it will be tracked there.

It’s git push -f that is the dangerous thing since it blows away the remote state. I would just be sure to be very precise since it’s operating without a safety net.

2 Likes

Let’s continue this discussion over on github.