[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Changes to the development model

From: CEL
Subject: [Discuss-gnuradio] Changes to the development model
Date: Mon, 26 Feb 2018 16:49:33 +0000

Hello everyone,

as the last days have been pretty heavy on discussion between the new
GNU Radio lead team, it’s now become clearer how we’ll actually deal
with the day-to-day maintenance work as well with the release

So, as you might have noticed, we’ve been crunching through the Pull
Request Queue on github. We weren’t able to merge all the PRs, but some
of these are blocked by the legal side of things, others simply need
small tweaks. What we were, however, able to do: Defining what should
be in release 3.7.12 (not all of this is visible on the PR tracker, but
we have a pretty good idea about it). So, once these remaining PRs are
closed, and all issues tagged with this milestone are solved, 3.7.12
will be released.

That release will also mark a radical change to the git workflow that
we’ll stick to:

We’re killing the idea that you usually submit PRs against maint. In
fact, there won’t be a maint branch anymore:

New releases will be tagged from the master branch. That means once we
released a version, for example 4.10, there will be a maint-4.10
branch, onto which we can merge fixes.
As versioning scheme, we’ll be adhering to Semantic Versioning, with
the first digit being the "paradigm" digit ("3" for the time being),
the second the "API" digit, meaning that we won't change how
programmers use GNU Radio without increasing the second digit, the
third being the "ABI" digit, meaning that as long as the first three
digit stay the same, you can just replace one libgnuradio*.so with
another one without rebuilding your binary (that's a feature that I
think software distributors will be most happy about), and the fourth
digit being the patchlevel.

The lifetime of these branches will reflect the life time of the
(primarily) Linux distributions that ship that package; it’s our
outspoken goal to not break GNU Radio for anyone who uses it on widely
used, actively maintained platforms. This will necessitate maintenance
of Long-Term Support releases.

Development happens on and against master. If there is a bug fix, we do
that on master (if it applies to master, at least), and backport fixes
to the maint-X.Y branches that we still support. This requires a bit of
consequence from PR authors: If you do happen to submit a PR that
contains a bug fix, please do note that in the PR itself, and make the
bugfix a commit of its own, so that it's easily cherry-pickable on the
appropriate maint-X.Y branch. We don't know yet whether that'll be easy
for every possible bugfix out there, but that's something we'd have to
figure out from case to case, anyways.

These branches are there so that distros etc. can get GNU Radio
bugfixes, and we don't force users to upgrade GNU Radio to "Bleeding
Edge" just to get a bugfix.

How does the "next" branch fit into this? Long story short: in its
current shape, it doesn’t. As soon we released the next 3.7.12 release
(which means tagging master “v3.7.12.0”), “master” becomes “maint-3.7”; 
“next” becomes “master”. The following release that we’ll do is 3.8, if
all goes well (but honestly, at this point, what shouldn’t?).
The v3.8.0.0 tagged commit will also the anchor of the “maint-3.8”
branch. Note that it’s not “maint-”. We'll limit the number of
heads we have to merge things into as far as possible (very much in the
sense of not letting this become a hydra).

Obviously, this implies that we have to increase the X.Y release
frequency. But: I think that’s totally doable. Only thing we need to
make sure is that our changelogs are really good enough for people to
track when features were added.

This all isn’t really easy to grok for people who’ve not worked with
medium-to-large git projects before, so I’ll have to make a nice
drawing and a blog post, but I recon it’s better to keep the mailing
list updated now than having a nice blog post in a month.

So, looking forward to countless PRs,


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]