Project

General

Profile

Actions

Task #3178

closed

Release 0.4.0-beta1

Added by Junxiao Shi about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Docs
Target version:
Start date:
Due date:
09/21/2015
% Done:

100%

Estimated time:

Description

Release ndn-cxx, NFD version 0.4.0-beta1.

  • write release notes, and update RELEASE_NOTES.rst and docs/RELEASE_NOTES.rst pointers
  • increment version number in wscript
  • publish source and binary packages
  • send announcement

Files

20150925112143.tgz (161 KB) 20150925112143.tgz integ with ndn-cxx 2301,15 and NFD 2477,4 Junxiao Shi, 09/25/2015 05:47 AM

Related issues 4 (0 open4 closed)

Blocks NFD - Task #3008: Release 0.4.0ClosedAlex Afanasyev

Actions
Blocks NFD - Feature #3166: TcpTransportClosedYukai Tu

Actions
Blocks NFD - Feature #3170: EthernetTransportClosedDavide Pesavento

Actions
Blocks NFD - Feature #3171: NDNLPv2 fragmentation and reassemblyClosedEric Newberry

Actions
Actions #1

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?

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.

Actions #2

Updated by Junxiao Shi about 9 years ago

Actions #3

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.

  1. 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.
  2. The only link that uses fragmentation is Ethernet multicast.
    When we leave EthernetFace unchanged, it's unaffected.
  3. 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 leave TcpFace TcpLocalFace unchanged, it's unaffected.
  4. 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:

Actions #4

Updated by Junxiao Shi about 9 years ago

Actions #5

Updated by Junxiao Shi about 9 years ago

Actions #6

Updated by Junxiao Shi about 9 years ago

  • Blocks Feature #3171: NDNLPv2 fragmentation and reassembly added
Actions #8

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
Actions #9

Updated by Alex Afanasyev about 9 years ago

  • Description updated (diff)
Actions #10

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".

Actions #11

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.

Actions #12

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?

Actions #13

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.

Actions #14

Updated by Junxiao Shi about 9 years ago

  • Description updated (diff)
  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100

0.4.0-beta2 release with #3236 fix is split to #3252.

Actions

Also available in: Atom PDF