Releases planned, merge of 3.7 next branch into master

The 3.7 ‘next’ branch is nearing completion, and will be stable enough
to
merge back into the ‘master’ branch very soon. I’d like to detail the
order that things will happen, so people can prepare.

First, we will tag and release a 3.6.4.2 tarball. This will be the last
3.6.4 maintenance release, and will have all the bugfixes that have
occurred since 3.6.4.1 was released two months ago. If you have
deployed
applications that use 3.6.4 or 3.6.4.1, this will be a low-risk update.
Git users will be able to check out the v3.6.4.2 repository tag to
update.

Then, we will tag and release a 3.6.5 tarball. This will be the new
stable
release, and will have both bug fixes and a set of new features using
the
current 3.6 API, the most significant of which is the new OFDM PHY code.
There are no API compatibility breaking changes, so upgrading to this
release shouldn’t force any changes to your application code, but there
may
be bugs in the new features. Git users will be able to check out the
v3.6.5 repository tag.

Given that the new 3.7 API will require a number of changes to GNU Radio
applications for compatibility, we’ll be supporting 3.6.5 with bug fixes
for awhile, even after 3.7.0 is released.

Finally, we are going to make the major leap and merge the 3.7 next
branch
back into master, and tag and release a 3.7.0rc0 tarball. For git
users,
once this happens, unless you take steps to check out the 3.6.5 release
tag, you will be using the new API, and your applications will need to
be
modified accordingly. Most of the required changes are mechanical,
involving renaming of classes and functions in C++ or importing modules
from different locations in Python. Git users that track the master
branch
will get this automatically when you pull.

For awhile there will be no ‘next’ branch, and most of the development
effort will be focused on addressing issues that arise from using the
new
API and stabilizing for the 3.7.0 release.

I anticipate that all the above will happen this weekend, unless our
final
planned merges and testing indicate that it isn’t yet time.

And don’t forget that we have a wiki page designed to help us
transition from the 3.6 API to 3.7:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

The page is not complete, though we are doing our best, so please help
us by adding and editing text on here as you find it or as things come
up on the mailing list.

Tom

On Thu, May 23, 2013 at 11:05 PM, Johnathan C.

I’m looking at these changes and trying to come up with a good way to
integrate them into the MacPorts gnuradio {release, devel, next} ports.
Updating the release to 3.6.5 seems like a good idea. I’d prefer to
keep the devel port on 3.6.5 + bug fixes, since that’s what it is
supposed to represent – will there be a GIT branch for the 3.6.5
series, kept separately from the post-next-merged master? Right now,
I’ll sent it to check out the 3.6.5 tag. Given that many projects out
there do not yet support the 3.7 API (e.g., gr-osmosdr, which I just
checked tonight), I’d like to keep the next port on the 3.7 API, which
is now the GIT master. I think this division makes sense, and is less
confusing to end-users from a MacPorts perspective (release is release,
devel is for bug-fixes on the release, and next is for the next API
purposes – the bleeding edge as it were). Thoughts? - MLD

Yes, this is exactly what I needed; thanks! - MLD

On Mon, May 27, 2013 at 6:59 PM, Michael D. [email protected]
wrote:

MacPorts perspective (release is release, devel is for bug-fixes on the
release, and next is for the next API purposes – the bleeding edge as it
were). Thoughts? - MLD

“release” → v3.6.5
“devel” → maint branch
“next” → master branch

It will be a few weeks at least before we’re ready to call 3.7.0 stable;
in
the interim, 3.6.5 is the stable release that everyone can use, with bug
fixes to that on the ‘maint’ branch.