Created attachment 211449 [details]
To ease the transition from helm 2 to helm 3 I'd like to propose introducing helm 2 as a "helm2" port.
I've also updated helm 2 to the the latest patch release of helm 2.
I'm not sure if there are special criteria to introduce such transition or legacy ports. If this is a completely outlandish idea, have mercy, I may have learned a bit or two about the technical aspects of ports but policy wise I'm quite unsure.
Should DEPRECATED be set for this port?
Hello Philipp, thank you for your patch. I agree that it's a good idea to add sysutils/helm2, I thought it would be deprecated soon but it's still being maintained.
lwhsu@ (I noticed you opened the bug report) in this case, the correct way to do that is doing a repo-copy  from sysutils/helm. Also, the dependencies can be added to GH_TUPLE . The revision found in this patch is from when I kept a tarball with all the modules. Now it can be solved with GH_TUPLE.
Philipp, do you want to take the maintainership of this port? Otherwise, lwhsu@
please, feel free to add the port and take the maintainership.
 - https://wiki.freebsd.org/PortsSubversionPrimer#Repo-Copy
 - https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/building.html#using-go
I'd be happy to give maintainership a shot and this does look like a reasonable place to start.
On a related note: In my day to day I've had the need to have both versions installed, which I managed manually by renaming the helm 2 binary to 'helm2'.
I feel there is some precedent on doing this, for example looking at python. Would this be reasonable? It seems like a thing to best do before adding the port as new.
As far as I understand for the repocopy there is nothing for me to do. I'll look into renaming and prepare a patch for that as well as the maintainer change.