[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] GNU Radio 3.1.0 Release Tarballs Available
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] GNU Radio 3.1.0 Release Tarballs Available |
Date: |
Tue, 23 Oct 2007 13:53:07 -0700 |
User-agent: |
Mutt/1.5.9i |
On Mon, Oct 22, 2007 at 07:05:43PM -0700, Johnathan Corgan wrote:
> GNU Radio stable release 3.1.0 is now available for download:
>
To emphasize what Johnathan already said:
> This new stable branch will be maintained such that existing Python and
> C++ code based upon it will not break due to updates in the series. New
> releases in this series will have backported bug fixes and new features
> added. However, no changes will be made that (intentionally!) result in
> existing user code not functioning.
>
> If it sounds like this means we *will* be making such changes on the
> trunk, you are absolutely right. Several features targeted for the 3.2
> stable branch will require deep surgery and will break user code that
> doesn't keep up:
>
> * Removal of gr.flow_graph(), leaving only gr.top_block() added in 3.1
> * Removal of gr.hier_block(), leaving only gr.hier_block2() added in 3.1
>
> Install and develop for the 3.1 stable branch if you want to avoid any
> issues, or work off the trunk and enjoy the ride.
We'll probably start tearing the old flow graph code out of the trunk
in the next 24 hours or so.
FAQ: Why are you doing this?
Answer: the 3.1 stable branch contains two parallel implementations of
more or less the same functionality. The old one is Python and C++,
the new one is pure C++. They do not build on a common core (except
at the very bottom). We want to move forward with the Cell port, a
new "thread-per-block" scheduler (SMP/SMT goodness) and gluing mblocks
and gr_blocks together. Ripping out the old code "clears the decks"
for the new development. The new stuff will support Python + C++
(like we do now), but will also enable all C++ development.
We don't intend to change the interface to the new
top_block/hier_block2 code, so if you've already converted your code
to use that, the trunk should remain a safe place for development.
If you're tracking the trunk, and have code that hasn't already been
converted to top_block/hier_block2 you'll probably want to consider
tracking the 3.1 stable branch instead of the trunk.
(See http://gnuradio.org/trac/wiki/BuildGuide for svn instructions)
Eric