good to know that a fix is on it's way for that problem with the dotnet toolchain. thanks for looking into that.
i'm +1 to publish an rc1 for 3.2.8/3.3.2 to nuget. we don't really have dev docs that describe the process of doing release candidates for just a GLV. when i've done it, I usually just ad-hoc my way through using various snippets of steps in the dev docs. For the last release candidate where we just published a GLV i think that I just tagged the repo at that spot: https://github.com/apache/tinkerpop/tree/3.3.1-rc1 and didn't bother to actually update the version to include the rc1. It seemed more important that we just know what the commit was for that development version. If we were doing a "full" release candidate (i.e. publish all convenience artifacts) I think we might want to do that differently. On Tue, Feb 13, 2018 at 11:38 AM, Florian Hockmann <f...@florian-hockmann.de> wrote: > We currently have the problem that we cannot deploy versions of > Gremlin.Net from non-Windows systems due to a problem with strong naming: > https://issues.apache.org/jira/browse/TINKERPOP-1880 > > Unfortunately, the already released versions 3.3.1 and 3.2.7 have a > broken signature as they were deployed from a Unix system. This makes > those packages unusable for use cases where the signature is checked > (that's what the ticket was originally about). > To fix this, I propose that we deploy development versions 3.3.2-rc1 and > 3.2.8-rc1 to nuget.org from a Windows system. > > This should only be a temporary problem as a PR that adds support for > strong-name signing on non-Windows systems is already merged [1]. > > If there are no objects within the next 72 hours, I'll assume lazy > consensus and proceed with the deployment. > > Regards, > Florian > > [1] https://github.com/dotnet/roslyn/pull/23061 > >
