-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecation of command #288
Comments
Note that |
Agree on the other two, no opinion about help :) |
In that case we could at least hide one and change the help of the other? |
Not sure I understand you now :) |
Of course if I look at the old haxelib and not the dev version :) I'd hide the deprecated from the help, that way the people who don't know about them wouldn't start using them. |
Agreed! |
Agreed as well! |
I added a deprecation method in the referenced commit, we'll use it for selfupdate when it becomes redundant. |
At some point we'll need to implement proper help system for our commands, so user can get to know that e.g. they can use |
Following #283 (comment)
I think these three commands should be deprecated:
Deprecation would mean to hide them from the help and show a notice when running them:
Warning: this command is deprecated, use "$replacement" instead, and will be removed in a later version.
Here
$replacement
would be (respectively):haxelib update haxelib_client
haxelib install file.zip
haxelib upgrade library
orhaxelib update
And the later version would most likely be the one released with haxe 4.
And while we are on the topic of hiding things I don't think we should show the entire help when haxelib is run without arguments, only the common things.
Things like: config, path, convertxml, newrepo, deleterepo, proxy, all flags but always could only appear when doing
haxelib help
.With that and the deprecated command the output would go from the currently long 38 lines to 25.
The text was updated successfully, but these errors were encountered: