I agree. It would be nice if we have vm-bhyve group on phab.

I have reintroduced the stable branch (1.7-stable) and am trying to avoid huge changes in v1.7.x releases. This is also intended to be tracked by the regular port.

It looks like a consistent approach, whether using a snapshot or a release tag. LGTM.

In D53837#1230007, @michaelo wrote:

In D53837#1230006, @driesm wrote:

So if we return to using a commit hash, it keeps working with versioning, then it seems reasonable to me.

The commit hash in the version string isn't sortable, that is why most ports use the ISO datestamp.

BTW, 1.7.0.gYYYYMMDD doesn't require PORTEPOCH bump.

I still want to use DISTVERSION=1.7.0 and not overwrite the version in post-patch. Because the commit e2ebcea and the tag v1.7.0 are identical, and point to the same commit. At this point, the tarball can be shared between vm-bhyve and vm-bhyve-devel. There is no need to keep tarballs with different checksums in distfiles when their contents are identical.

I think we can update sysutils/vm-bhyve-devel to 1.7.0 as well. Both are currently at the same version since only a few commits have been added after the release.

Nothing had happened for over a year since D45854 was submitted. I just tried to get things moving to avoid waiting another year. Because we didn't get feedback from you after the reviewers left review comments, and the deadline was approaching.

This worked very well for me, both for EtherIP (Ethernet-ovet-IPv6) and IPIP (v6-over-v6).

Will it happen soon? I don't believe hrs can spend much time on this. We need to work on this instead. I'll try to resolve conflicts and submit another review.

Would it be possible to include this in 15.0-RELEASE? I worked on D51297 to ensure that the fix for bug 280736 would be included in the release, as there has been no progress on D45854 for over a year. Since this is a better approach for bug 280736, it should be included as well.

I only have ports commit bit so I'm not sure I'm eligible to approve this but it LGTM now.

Tested, it works fine for me both for IPIP and EtherIP. It is a much simpler and good approach. BTW, it conflicts with after D51835.

Quickly reviewed for typos in manpages. I will test the code changes later.