Maybe not in first version but in the future we can add a --path to the CLI

On my ubuntu :

mvn --version
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)
Maven home: /home/fabien/.sdkman/candidates/maven/current
Java version: 10.0.2, vendor: Oracle Corporation, runtime: /home/fabien/.sdkman/candidates/java/10.0.2-open
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.3.0-19-generic", arch: "amd64", family: "unix"

$ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /home/fabien/.sdkman/candidates/maven/current
Java version: 10.0.2, vendor: Oracle Corporation
Java home: /home/fabien/.sdkman/candidates/java/10.0.2-open
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.3.0-19-generic", arch: "amd64", family: "unix"

Add python 3.8 in the CI once it is possible

According to this graph 3.6 will still exist for along time.

It would be nice to support it if it does not require too many changed.

3.5 is end of life in less than a year so I think it's ok to not support it.

This workflow should :

• release to pypi
• release to conda
• deploy documentation

Define a type that must be generic and comparable, similar to sys.version_info in python

php -v should work

Example output from SO :

> php -v

PHP 5.6.26 (cli) (built: Sep 15 2016 18:12:07)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

other example from php.net

$ php -v
PHP 5.3.1 (cli) (built: Dec 11 2009 19:55:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

Deploy on main conda channel so conda users can use it.

On my ubuntu I can do go version which returns :
go version go1.12.10 linux/amd64

other Ubuntu results found on SO :
go version go1.1.1 linux/amd64
go version go1.6beta1 linux/amd64

Also version with only major minor on medium :
go version go1.8 linux/amd64

Windows looks similar on this blog
go version go1.10 windows/amd64

And apparently similar on macos :
go version go1.13.3 darwin/amd64

Beta version : go version go1.11beta1 darwin/amd64

Could not find any alpha or rc

It would be so nice to add support for helm.
Currently, the version is a bit too technical.

Client: &version.Version{SemVer:"v2.15.1", GitCommit:"cf1de4f8ba70eded310918a8af3a96bfe8e7683b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.15.1", GitCommit:"cf1de4f8ba70eded310918a8af3a96bfe8e7683b", GitTreeState:"clean"}

It would be nice just to have the semver, that is 2.15.1.
I don't know if this should make a distinction between client and server or simply return a tuple.

Support for Java, probably something similar to that SO post

Add test cases, this probably require a test framework too

semver is a classic way of versioning.

with a parser for semver string it become easier for anybody to add a tool that uses semver

1.0.0 should be greater than 1.0.0-pre

It would be so nice to add support for kubectl.
Currently, the version is a bit too technical.

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.6-eks-5047ed", GitCommit:"5047edce664593832e9b889e447ac75ab104f527", GitTreeState:"clean", BuildDate:"2019-08-21T22:32:40Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

It would be nice just to have the git version, that is 1.16.2.
I don't know if this should make a distinction between client and server or simply return a tuple.

This is obviously a big priority

Use git actions CI to test the PRs.

I agree with @Kineolyan that universions should be usable as a CLI command.

I add into the roadmap for 1.0.0

I will also create a tag for the CLI issues

Would be nice to have

• to see what versions are installed on a computer
• to quickly check universions anywhere and see if it works as expected

>>> universions --all
Found versions : 
  - java: 11.0
  - node: 12.6

Not found : 
  - npm
  - yarn

Failures : 
  - kubectl

This force to specify setup_tool as a dependency for run in the conda recipe which I don't want.

That seems to be the reason why the conda build fails.

Here someone had the same problem

It seems that a lot of people are interesting to know the CUDA version in this stackoverflow post

This should be easy based on this answer

Support for node versions

Deploy the lib on pypi so everyone can use it easily

Currently, the Github actions are running when a fork updates its master branch.
This causes the release workflow to be run and particularly trying to release the documentation.
As there are no way to control the state of those distant master branches, it is safer to prevent them from releasing anything.