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