Hello Marcus, I believe this workflow is an excellent improvement and stepping stone to acknowledge that GNU Radio is now a "medium-to-large" size projects.
Only thing I did not understand was the connection with Linux Distros. I think you want to say that suppose 3.7.12 version is released, then the corresponding maint-3.7.12 will be active only for a given timeframe? Is that correct? How long would that timeframe be? Looking forward to the blog post! Regards, Kartik Patel On Mon, Feb 26, 2018 at 10:49 AM, Müller, Marcus (CEL) <[email protected]> wrote: > 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 > management. > > 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-3.8.0.0”. 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, > > Marcus > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
