sysutils/vm-bhyve-devel: Upgrade port to commit e2ebcea

[michaelo]

Summary

Approved by: driesm (maintainer)
MFH: 2025Q4
Release Notes: https://github.com/freebsd/vm-bhyve/releases/tag/v1.7.0

[driesm]

sysutils/vm-bhyve-devel/Makefile

18

Is this one really needed? Does the default not work anymore?

[michaelo]

sysutils/vm-bhyve-devel/Makefile

18

I have tried. It didn't work for me. I took it from the textbook, actually (Porter's Handbook).

[driesm]

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]

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.

[michaelo]

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

[meta]

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.

[michaelo]

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.

[driesm]

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

[meta]

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

$ pkg version -t 1.7.0.g20251112 1.7.1
<

[driesm]

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

[michaelo]

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.

[driesm]

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.

[meta]

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.

[michaelo]

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.

[driesm]

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

DISTVERSION= 1.6.2-34
DISTVERSIONSUFFIX= -g73b127

[michaelo]

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.

[driesm]

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.

Good idea! #shipit

[michaelo]

Rework to "git describe --tags"

[meta]

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

[driesm]

I'm just wondering, given we have frequent releases now, does it still make sense to keep the devel version around?
It was more like a workaround to get the latest and greatest commit from to original repo (not FreeBSD umbrella hosted).
This need seems more or less vanished now :-). happy to hear your thoughts.

[michaelo]

In D53837#1242218, @driesm wrote:

I'm just wondering, given we have frequent releases now, does it still make sense to keep the devel version around?
It was more like a workaround to get the latest and greatest commit from to original repo (not FreeBSD umbrella hosted).
This need seems more or less vanished now :-). happy to hear your thoughts.

Good question. I think we can re-evaluate this in a couple of months, I tend to agree with you!

[meta]

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.

At the same time, relatively major changes are being made in the master branch, which is planned to be released as the future v1.8 series. So what about tracking the master branch in the -devel port for the pre-release evaluation?

[driesm]

Thats fine for me, so for now, the normal port tracks releases from 1.7 (so I update it to 1.7.1). And the devel port I will update to track latest commit in main.

[driesm]

There is a small issue atm,; v1.7.0-30-ge88102c is the main branch, so basically the release port will be at a higher dot version as to the devel version, even though the devel version will be ahead for around 15 commits.

[driesm]

Also, I'm fine with "vm-bhyve" umbrella updating the port. Can we create a group in phab for that?

[driesm]

Like this; https://reviews.freebsd.org/owners/package/2/

[meta]

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