NFD » ndn-cxx

I don't want to delay everything by five days

As soon as the initial code is ready, you can send email notice to ndn-lib and nfd-dev.

where does it say we have to delay by 5 days for breaking changes?

Felix Rabe demanded this a few years ago.
0.6.1 cycle was an exception because a general breaking changes notice about certificate v2 was sent.

I don't think the end user is required to specify a name that already includes the sequence number component to the fetch function. This is added by the retrieval logic inside SegmentFetcher.

That's not what 4651,6 does. Either way is fine.

Junxiao Shi wrote:

I don't think the end user is required to specify a name that already includes the sequence number component to the fetch function. This is added by the retrieval logic inside SegmentFetcher.

That's not what 4651,6 does. Either way is fine.

No, 4651,6 definitely adds the segment component to the Interest.

Eric Newberry wrote:

Junxiao Shi wrote:

I don't think the end user is required to specify a name that already includes the sequence number component to the fetch function. This is added by the retrieval logic inside SegmentFetcher.

That's not what 4651,6 does. Either way is fine.

No, 4651,6 definitely adds the segment component to the Interest.

There's actually a typo (the last component of the base Interest name will be incorrectly removed) but the above statement still holds.

Junxiao Shi wrote:

Change 4561 patchset 6 changes interest.setChildSelector(1) to interest.setCanBePrefix(false). Consequently, the caller of SegmentFetcher::fetch is expected to pass an exact name including version number and segment number components, and SegmentFetcher would not attempt to prefer the latest version.
While I support adopting this new semantics, it must be performed in a separate commit under this issue, not combined with another change. A 5-day breaking change notice is also required.

But don't we want to prefer the latest version? If I'm understanding the above correctly, these semantics would not prefer the latest version.

Eric Newberry wrote:

Junxiao Shi wrote:

Change 4561 patchset 6 changes interest.setChildSelector(1) to interest.setCanBePrefix(false). Consequently, the caller of SegmentFetcher::fetch is expected to pass an exact name including version number and segment number components, and SegmentFetcher would not attempt to prefer the latest version.
While I support adopting this new semantics, it must be performed in a separate commit under this issue, not combined with another change. A 5-day breaking change notice is also required.

But don't we want to prefer the latest version? If I'm understanding the above correctly, these semantics would not prefer the latest version.

Or would MustBeFresh=true handle this?

But don't we want to prefer the latest version? If I'm understanding the above correctly, these semantics would not prefer the latest version.
Or would MustBeFresh=true handle this?

There isn't a simple way to ensure the latest version (#4396), but CanBePrefix=true MustBeFresh=true prefers the latest version, and thus preserves the previous semantics.

Junxiao Shi wrote:

But don't we want to prefer the latest version? If I'm understanding the above correctly, these semantics would not prefer the latest version.
Or would MustBeFresh=true handle this?

There isn't a simple way to ensure the latest version (#4396), but CanBePrefix=true MustBeFresh=true prefers the latest version, and thus preserves the previous semantics.

Ok, thanks for the clarification.