Task #3178
closedRelease 0.4.0-beta1
100%
Description
Release ndn-cxx, NFD version 0.4.0-beta1.
- write release notes, and update
RELEASE_NOTES.rst
anddocs/RELEASE_NOTES.rst
pointers - increment version number in
wscript
- publish source and binary packages
- send announcement
Files
Updated by Junxiao Shi about 9 years ago
The purpose of a 0.4.0-beta1 release to give library and application developers a chance to adapt to the breaking change to be introduced by NDNLPv2 in 0.4.0 release.
What is the breaking change in 0.4.0?
Previously, network-layer packets (Interest and Data) are directly transmitted on NFD faces, except that
(1) local application face has the option to use LocalControlHeader to carry additional information;
(2) Ethernet face talks in NDNLPv1.
0.4.0 contains NDNLPv2 implementation, which changes all faces to talk in NDNLPv2.
NFD 0.4.0 can accept bare Interest/Data, but all outgoing packets are LpPacket.
This is incompatible with libraries designed for previous versions.
What should be included in this release?
- #2930 ndn-cxx send/receive LpPacket
- #3088 LpFace
- #3165 UnixStreamTransport in face refactoring
- #3168 UdpTransport in face refactoring
- part of #3104 GenericLinkService, at least: encoding/decoding of LocalControlHeader-equivalent fields
- #3177 counters in LpFace
- #3156 NACK in forwarding and best-route strategy
What should not be included in this release?
- #3166 TcpTransport
How should we deploy this release?
0.4.0-beta1 requires a flag day for testbed routers: deploy on all testbed routers at the same time.
After deployment on testbed, end hosts connecting to the testbed via UDP would stop working because they cannot understand incoming NDNLPv2 packets.
They can connect to the testbed via TCP, which is still talking in old format.
When an end host is upgraded, ndn-cxx applications are not affected because #2930 changes ndn-cxx to talk in LpPacket.
Applications using other libraries would stop working because they cannot understand incoming NDNLPv2 packets.
They can connect to NFD via TCP on the loopback IP, which is still talking in old format.
How to upgrade old end hosts?
An end host upgrading to 0.4.0-beta1 should connect to the testbed via UDP.
Applications with upgraded libraries should connect to NFD via UNIX socket.
Upon 0.4.0 release, upgraded end hosts and applications won't be affected because packet format on UDP and UNIX socket is unchanged.
End hosts and applications that have not been upgraded (and are connected via TCP) will stop working.
Updated by Junxiao Shi about 9 years ago
20150910 conference call agrees that 0.4.0-beta1 release is necessary and beneficial, but it does not need to be a change that breaks all existing end hosts and libraries.
LpPacket
should be encoded as bare Interest/Data, if no header field is present.
With that, an NDNLPv2 sender would send bare Interest/Data except when fragmentation or LocalControlHeader-equivalent fields are used, and bare Interest/Data can be understood by a non-NDNLPv2 receiver.
This limits the change to break only those links with fragmentation, and those applications that uses LocalControlHeader.- The only link that uses fragmentation is Ethernet multicast.
When we leaveEthernetFace
unchanged, it's unaffected. - ndn-cxx and jNDN are the only two supported libraries that support LocalControlHeader.
ndn-cxx will be upgraded in #2930 together with NFD, so there's little impact.
jNDN connects to NFD via TCP, so when we leaveTcpFace TcpLocalFace
unchanged, it's unaffected. - All supported libraries will ignore a packet with unknown top-level TLV-TYPE, so if an LpPacket such as a NACK is returned to those libraries, they will just drop the LpPacket without causing an error.
The new plan is:
Updated by Junxiao Shi about 9 years ago
- Blocks Feature #3166: TcpTransport added
Updated by Junxiao Shi about 9 years ago
- Blocks Feature #3170: EthernetTransport added
Updated by Junxiao Shi about 9 years ago
- Blocks Feature #3171: NDNLPv2 fragmentation and reassembly added
Updated by Junxiao Shi about 9 years ago
- File 20150925112143.tgz 20150925112143.tgz added
Updated by Alex Afanasyev about 9 years ago
- Status changed from New to In Progress
- Assignee set to Alex Afanasyev
- % Done changed from 0 to 50
Updated by Junxiao Shi about 9 years ago
- Description updated (diff)
The announcement http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2015-September/000849.html is incorrectly referring to the release as "release candidate 1". It should be "beta 1".
From Wikipedia:
A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge.
0.4.0 is expected to have NDNLPv2 on all transports. The difference between the current release and 0.4.0 is much more than "significant bug".
Therefore, it's semantically wrong to refer to the current release as a "release candidate".
Updated by Junxiao Shi about 9 years ago
Unfortunately the release still breaks one scenario: when UNIX sockets are disabled, NFD-RIB attmepts to talk to NFD over TCP. ndn::TcpTransport
on RIB side is talking NDNLPv2, but nfd::TcpLocalFace
on NFD side is talking LocalControlHeader. This eventually leads to "prefix registration timeout" error on RIB thread and terminates nfd process.
Updated by Davide Pesavento about 9 years ago
- % Done changed from 50 to 80
Do we want to publish source tarballs for the beta/rc, or is the git tag sufficient?
Updated by Junxiao Shi about 9 years ago
A high-priority Bug #3236 is being fixed.
I suggest delaying binary release to incorporate the fix.
At that time, a new git tag should be created for "beta2" and then binary packages can be created based on that.
Updated by Junxiao Shi about 9 years ago
- Description updated (diff)
- Status changed from In Progress to Closed
- % Done changed from 80 to 100