Re: [mosquitto-dev] [Roger Light] Re: [eclipse/mosquitto] cmake build in

[Greg Troxel <gdt@xxxxxxxxxx>]

Roger Light <roger@xxxxxxxxxx> writes:

> Glad you got it sorted.
>
> The model used is a simplified (due to the size of the development
> team) version of
> https://nvie.com/posts/a-successful-git-branching-model/ , where the
> principle that the master branch is always a stable version is
> introduced.

Thanks.  I read that long ago, but just didn't expect it here as I
rarely encounter it.  I should have spotted it, and I didn't fire up
gitk like I should have.

While I strongly agree with the notion of bugfixes only on release
branches, I find the pivot of master to develop and putting releases on
master something that is much more confusing than helpful.  My more
serious problem with this model is that it leads to not having named
branches for releases because there is a single release branch for all
time.

For example, in the current repository, today, master is the stable
release branch for 1.6.x.  Presumably, if code not meant for 1.6 were to
land on develop, then any bugfixes would be made on master, and merged
to develop.  But now, bugfixes for stable are on develop and merged to
master.

What if there is a security bug found in 1.5, and for whatever reason it
is desired to apply a fix and release a 1.5.(n+1)?  Or even 1.4?  There
is no branch name for the 1.5.x stable branch; it's just what master had
at some point in the past.

Another, more minor problem, with this model is that because of the
expectations associated with the word master as the place where
development happens, master in the develop model seems to have a
tendency to not be treated as strongly as a release branch as when the
release branch actually has a release-x.y name.

Thus, I prefer to have regular development on master (although the name
is unimportant), and for each release series, a branch named for the
series.  The old branches simply remain, and thus are available for easy
application of security bugfixes if that turns out to be warranted.

So one would have

  master: branch where new work happens

  release-1.6: branch where commits land that are intended for the next
  1.6.x release.  Could be created before 1.6.0, and could be created with
  a 1.6.0 tag to denote the release of 1.6.0 from master

  release-1.5: same, but from 1.5

This may end up being the same graph of commits, but with what I
consider to be much clearer branch labels.


Looking at the repo, it seems a bit of cleanup is in order:

  branch "fixes" - no longer useful, delete?

  two branches named debian and debian-mosquitto.  Seems like they are
  for the same purpose, and I am guessing that is to keep debian
  packaging files out of the standard view and releases.

  It seems master should be merged into the debian branch

  I don't understand coverity and coverity-fixes, and why that is at v1.6


And I don't see why the website update was on master rather than develop
(other than that usually master is where development happens!).


Of course none of this is super important, but I think it's good to
clean up old branches (other than release branches) to reduce confusion,
and I think it's good to have named release branches.