[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016209#comment-16016209
]
ASF GitHub Bot commented on TINKERPOP-1552:
-------------------------------------------
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/600
Ok, so for Java you can simply publish new `SNAPSHOT` packages and clients
will always take the latest version?
That won't work for NuGet as it will first search for the package with the
specified version in its local cache. So a user will always use the first
_version_ of the package with a version as `3.2.5-SNAPSHOT` that was retrieved
from nuget.org. He won't get any updates after that until we publish a package
with a higher version such as `3.2.5-Z`, because he already has the package
with the version `3.2.5-SNAPSHOT` in his cache.
The solution mentioned in that comment suggests that users don't explicitly
specify the version number in their projects. Instead they can specify the
version as `3.2.5-*` (instead of `3.2.5-beta01` for example) which means that
they always get the latest pre-release version, but that still requires later
packages to have a higher version number. (That solution was also specific to
the now obsolete `project.json` project format and I am not sure if it still
works exactly like that.)
So we definitely have to increase the version number somehow when we want
to publish updates. We basically have the following options for that:
1. A fixed tag such as `SNAPSHOT` or `beta` plus a number that has to be
manually incremented each time we change something (to Gremlin-DotNet or
Gremlin-CSharp): `3.2.5-beta01`, `3.2.5-beta02`, ...
2. A fixed tag plus a build tag that is set during the build process (for
example by Travis): `3.2.5-beta-build1234`, `3.2.5-beta-build1235`, ...
xUnit uses a combination of both and also goes through `alpha`, `beta` and
`rc`.
But since there probably won't be that many changes to Gremlin-CSharp or
Gremlin-DotNet my personal preference is that we simply increment a number in
the suffix manually each time a change is merged into the C# GLV branch. So we
could start for example with `3.2.5-beta01`.
> C# Gremlin Language Variant
> ---------------------------
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
> Affects Versions: 3.2.3
> Reporter: Jorge Bay
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of
> the trickier bits to deal with.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
