Hello Marcus, All I wanted to know was the typical time frame of the maint-X.Y branch (not 3.7 in specific). I believe the answer is (from your reply), it will depend on the particular version. Maybe maint-3.7 will have a long life and other maint-X.Y may not.
With the Debian and QT4 example, it's more clear on why we need this. I am not worried about anything in particular though. It was a general question for more information on this workflow. Thanks for the detailed response. :) Regards, Kartik Patel On Mon, Feb 26, 2018 at 4:18 PM, Müller, Marcus (CEL) <[email protected]> wrote: > Hello Kartik, > > there will not be a "maint-3.7.12", there will only be a "maint-3.7"; > that's enough fragmentation for me :) > > Yes, it will be actively maintained for a finite time, just like > anything in this world :) That timeframe probably will be a bit longer > than for future maint-X.Y branches, as 3.7 has been around for so very > long that there's by now a lot of software that actually relies on all > the special kinks and features that GNU Radio 3.7 has, and we don't > want to stop supporting any of that! > Still, it's important to be forward-facing: Dependencies are always > moving, and for example, without extensive manual labour of Maitland, > GNU Radio 3.7 would already have been thrown out of Debian because it's > still using Qt4! We must work on all contributions, especially user- > facing stuff like GUI frontends, become compatible with 3.8; don't > worry, we won't realease 3.8 without making sure it's usable, nor will > we abandon versions that are widely used. > > What I cannot tell you at this point is how many years the support for > maint-3.7 will go on. Time will tell, and if there's high demand, we > might at some point even find a maintainer just for that branch who's > job would be to backport patches and keep 3.7 alive for those who can't > switch. Again, this is by no means us trying to abandon existing users, > this is us being very worried that you won't even be able to build > upstream GNU Radio on mainstream linux distros for much longer, and > actively working on making it work for the future, thus, ensuring that > applications continue to run, with as little modification as possible. > > Does that answer your question? Are you worried about something in > particular? This is an excellent time to come forward about that, > either here or in private, if it's something sensitive; the GR > leadership is more than interested in not breaking everyone's use case! > > Best regards, > Marcus > > On Mon, 2018-02-26 at 11:16 -0600, Kartik Patel wrote: > > 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] > > du> 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 > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
