User Details
- User Since
- Aug 25 2018, 5:03 PM (386 w, 5 d)
Fri, Jan 16
Also, I'm fine with "vm-bhyve" umbrella updating the port. Can we create a group in phab for that?
Wed, Jan 14
Sat, Jan 3
Fri, Dec 26
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.
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.
Dec 23 2025
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.
Dec 14 2025
Dec 7 2025
Nov 20 2025
@michaelo, I rather we keep the bellow fields. You can get them from using git describe --tags.
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?
So if we return to using a commit hash, it keeps working with versioning, then it seems reasonable to me.
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.
Sounds good, go for it!! Lets MFQ the -devel port as @meta suggested.
Nov 18 2025
Nov 16 2025
Nov 14 2025
Nov 10 2025
Nov 6 2025
Nov 1 2025
Oct 28 2025
Oct 6 2025
Oct 5 2025
Oct 2 2025
If it passes poudriere, looks good 2 me!