Bar wrote:
I have been posting basically branches for testing here: Interstitial Firmware Releases - #571 by dlang
the problem is that there is no difference between a testing branch and a
release. When you announced interstitial releases, you made it sound like those
were supposed to be testing releases, but they aren’t, any release you make is a
release, with a new version number.
now that we have the builds being named via tags, we can talk again about doing
this.
apologies that this is long and technical, it covers a lot of ground and I don’t
want to take shortcuts. It seems complicated, but in practice it’s not, and it
will reduce the unintended bugs from new features enough to save considerably
more time than it takes (and large amounts of it can be automated)
*** Defining version numbers ***
v1.15 is a release
v1.15.2 is the 2nd bugfix of v1.15
v1.15-5-gadba is a test build (5 commits past v1.15)
v1.16-rc2 is a release candidate for 1.16
v1.15.3-rc1 is a release candidate for v1.15.3
v1.15-5-gadba is a build from the main branch at that point in time (and we
should do nightly builds and have people able to follow them). This is the 5th
commit past v1.15 and has a git hash of adba, I will just show this type of
version as v1.15-5-g for simplicity going forward.
***The workflow would be: ***
hack-hack-hack, the master branch changes.
Each commit that is added will change the version
v1.15 becomes v1.15-1-g with the next commit, then v1.15-2-g, …
Each night a build is made and this is the interstitial or ‘nightly’ release for
those brave souls interested in testing the latest and greatest.
hack-hack-hack, your tree is now at v1.15-75-g (75 commits since v1.15)
you think things are good, it’s time to make a release
you make a branch ‘v1.16’ and tag the tree as v1.16-rc1
it gets built and released as a release candidate build
if nobody reports problems with testing, you tag it as v1.16
since development doesn’t ever completely stop (and we are optomistic that the
work we’ve done is correct and no fixes are going to be needed), while this is
happening, additional stuff happens in the main branch and v1.15-78-g is newer
than v1.16-rc1
someone finds a bug in v1.16-rc1, you make a fix that is v1.15-79-g and test it.
you then backport that fix (cherry pick that commit) to the v1.16 branch and tag
it v1.16-rc2 (and this technically invalidates all testing that was done on rc1,
in practice, if it’s a small fix, not all testing is re-done, but as much as
practical should be)
when you tag v1.16, you rebase main on it (since every fix that went into a
v1.16-rc was first in your main branch, this should be trivial, but there may be
some trival merge conficts to resolve if development hasn’t slowed enough
hack-hack-hack you are now at v1.16-10-g and someone discovers a bug in v1.16,
so you fix the bug and it is v1.16-11-g in the master branch, your fix isn’t
perfect so you now have v1.16-12-g as a version with the right fix.
you don’t want to release the master tree as v1.17 (what we’ve done up until
now) because it also has 10 unrelated commits that could cause problems.
so you go to the v1.16 branch and cherry-pick the v1.16-11-g and v1.16-12-g
commits and tag it as v1.16.1-rc1 (otherwise it would show up as v1.16-2-g)
people test it, confirm it works and you then tag it as v1.16.1
hack-hack-hack you are now at v1.16-50-g and it’s time to make a release (see
above)
Note: I am of the ‘release early, release often’ camp, we should not get to
50-75 commits in a release, it should be more a matter of “it’s been X weeks
since the last release, time for the next one” than “there are lots of new
features, we need to get them out” the fact that v1.13 had close to 200 commits
shows we should have released at lot sooner.
more frequent releases mean that there is less to test each release, and while
each commit invlidates all prior testing, testing can be concentrated on the
areas we have changed.
people can enable automated updates and get the latest stable, nightly, or
rc + stable releases, depending on what level or risk they are willing to live
with.