sysutils/vm-bhyve-devel/Makefile
18	I'm not in front of my test machine atm, but if we need it, lets make it that we only need to update the commit once in the Makefile. eg: DISTVERSIONSUFFIX= -g${GH_TAGNAME} should work I think

meta added inline comments.Thu, Nov 20, 9:03 AM

sysutils/vm-bhyve-devel/Makefile
18	I intended to update -devel port in the same way as the regular port. Because the -devel port is v1.7.0, exactly the same as the regular port at the moment. The only difference is PKGNAMESUFFIX. Next time we update to a pre-release snapshot, let's use the DISTVERSIONSUFFIX again.
35	I think this is not necessary, since we're trying to update to a release version, not a snapshot. When we update to 1.7.0+some commits, let's restore this.

Update distname and tag name according to Porter's Handbook: https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github-ex2

Harbormaster completed remote builds in B68755: Diff 166824.Thu, Nov 20, 9:05 AM

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.

However, this version is now acceptable to me. Feel free to land if it looks good to @driesm.

In D53837#1229977, @meta wrote:

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.

However, this version is now acceptable to me. Feel free to land if it looks good to @driesm.

My motivation was to keep it consistent with the -devel approach, that is, always work from a commit (like other ports) and use the current version in the commit. Whether the current commit is identical to a tag or not should not matter from a -devel perspective. You are running of main, basically.

Hmmmm we should test going to newer versions to avoid a PORTEPOCH bump if we change versioning scheme now, and then want to come back to it later.

I rather like the current approach of the port pointing at a commit.

Normally you only need to change fields shown by: git --describe --tags
and this in the root of the pulled repo from git

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

$ pkg version -t 1.7.0.g20251112 1.7.1
<

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

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.

So when I'm understanding correctly, we switch to the ISO timestamp forever.
And in the future when the -devel and normal port diverge more, we use the commit hash and update the iso timestamp to the commit hash in question?

Seems fine for me.

This revision is now accepted and ready to land.Thu, Nov 20, 10:40 AM

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.

The string generated by git describe as @driesm mentioned is sortable, v1.7.0-1-gf2dddda means 1 commit ahead of v1.7.0, and the commit hash is f2dddda.

I leave the decision to @driesm, the current maintainer.

In D53837#1230008, @driesm wrote:

So when I'm understanding correctly, we switch to the ISO timestamp forever.
And in the future when the -devel and normal port diverge more, we use the commit hash and update the iso timestamp to the commit hash in question?

Seems fine for me.

Correct. The timestamp reflects the instant when you have touched the port to supply a new commit hash. From user's PoV the hash does not matter because the source is an implementation detail of the port.

@michaelo, I rather we keep the bellow fields. You can get them from using git describe --tags.

DISTVERSION= 1.6.2-34
DISTVERSIONSUFFIX= -g73b127

In D53837#1230021, @driesm wrote:

@michaelo, I rather we keep the bellow fields. You can get them from using git describe --tags.

DISTVERSION= 1.6.2-34
DISTVERSIONSUFFIX= -g73b127

Then I will add a comment how to produce them since I had no clue that Git produces them.

In D53837#1230022, @michaelo wrote:

In D53837#1230021, @driesm wrote:

@michaelo, I rather we keep the bellow fields. You can get them from using git describe --tags.

DISTVERSION= 1.6.2-34
DISTVERSIONSUFFIX= -g73b127

Then I will add a comment how to produce them since I had no clue that Git produces them.