Output of helm version:
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:54Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Openstack private cloud

Using helm template I've been creating releases no problem for a long time with my deployment hard-coded to apiVersion of extensions/v1beta1.
I updated my template to change it to apps/v1 in preparation for kube 1.16.0 later this year.
I use helm upgrade --install when I create releases.

The deployment still ends up having extension/v1beta1

helm template produces the output with apps/v1
after helm -upgrade --install (with or without helm delete --purge beforehand) the helm get manifest shows apps/v1 for the deployment.
however when you look at the deployment it remains apiVersion of extenstions/v1beta1

Any other changes in my values file or in the template itself works fine.
I have an annotation that creates a uuid which forces pods to roll no matter what for every upgrade even if no changes to the manifest. However the deployment value apiVersion remains at extensions/v1beta1 no matter what.

I even dumped the existing deployment yaml, edited the apiVersion to apps/v1 and applied it using kubectl apply -f. this was successfully applied but when I get the deployment yaml again, the version remains extenstions/v1beta1

I suppose this last bit might prove it not to be a helm issue but rather a kubernetes....