I discussed this submission with dteske on IRC and possibly have a few suggestions:

PORTNAME should correspond to the naming convention of installed files and usecase whenever possible, so dwatch-json --> dwatch-json-net and preferably libexec/dwatch/json-net* --> libexec/dwatch/dwatch-json-net*

Grafnet should be broken out, put in a separate port and be set as a dependency (if required) as it doesn't seem to be a hard requirement and/or limited to dwatch-json-net looking at pkg-descr

In D36051#818573, @diizzy wrote:

I discussed this submission with dteske on IRC and possibly have a few suggestions:

PORTNAME should correspond to the naming convention of installed files and usecase whenever possible, so dwatch-json --> dwatch-json-net and preferably libexec/dwatch/json-net* --> libexec/dwatch/dwatch-json-net*

Grafnet should be broken out, put in a separate port and be set as a dependency (if required) as it doesn't seem to be a hard requirement and/or limited to dwatch-json-net looking at pkg-descr

It is true that this was discussed. However, I tried to enlighten that:

1. Files in $PREFIX/libexec/dwatch are modules and the filename is both the module name and what the user types to invoke the module. It would not only be redundant to force people to type "dwatch -X dwatch-json-net" when there are dozens of profiles in the base Operating System in /usr/libexec/dwatch and other ports (authored by me, such as dwatch-gource) which follow the standard of NOT including "dwatch-" in the dwatch module name. For additional information on how dwatch modules work and are expected to be formatted, see the BSDCAN 2018 slides for my presentation on dwatch at https://fraubsd.org/doc/bsdcan/2018/

2. The PORTNAME argument ignores my other work and unnecessarily asks me to change the name of the port and then later change it back when I add non-network-related JSON modules.

3. The argument that dwatch-json is not a hard requirement [of grafnet] is patently false. Requiring authors to internally document in pkg-descr that files that are part of a package rely on other files inside the same package seems overly burdensome.
   
   https://github.com/FrauBSD/dwatch-json/blob/bc978e4d6d6b075f5426c01d85217132c9d7d63a/grafnet/grafnet#L545 https://github.com/FrauBSD/dwatch-json/blob/bc978e4d6d6b075f5426c01d85217132c9d7d63a/grafnet/grafnet#L400

From my 2018 BSDCAN presentation slides, here are the modules in base ... we're not going to add "dwatch-" prefix to all those simply because a PORT convention says that a PORT should install files named the same as the PORT when the PORT should follow BASE convention already set forth 6 years ago

You’re probably already aware, but ports has a commit hook so that commit messages should start the first line with “category/portname: description”.

So commit message should have first line:
sysutils/dwatch-json: update to 1.1, restore maintainership

In D36051#824457, @woodsb02 wrote:

You’re probably already aware, but ports has a commit hook so that commit messages should start the first line with “category/portname: description”.

So commit message should have first line:
sysutils/dwatch-json: update to 1.1, restore maintainership

Thanks! Was not aware of this (new) hook.

I was working on committing this and went to go apply the patch to the tree and the patch no longer applies cleanly.

I check the Makefile, and find that the current version is 0.6.3? But I didn't update it. And 0.6.3 isn't the latest version.

Currently investigating how the current version bumped from 0.4.1 (the last version I put up for ports) to 0.6.3 when I was working towards merging this approved commit to bump it to 1.1