Skip to content
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

Closed
ibilon opened this issue Mar 10, 2016 · 9 comments
Closed

Deprecation of command #288

ibilon opened this issue Mar 10, 2016 · 9 comments

Comments

@ibilon
Copy link
Member

ibilon commented Mar 10, 2016

Following #283 (comment)

I think these three commands should be deprecated:

  • selfupdate
  • local
  • either update or upgrade (and update the help message of the other)

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
  • either haxelib upgrade library or haxelib 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.

@nadako
Copy link
Member

nadako commented Mar 10, 2016

Note that upgrade and update commands were unified in bfcd9ca and I think we can keep it this way, it's just handy not to care whether you type update or upgrade.

@nadako
Copy link
Member

nadako commented Mar 10, 2016

Agree on the other two, no opinion about help :)

@ibilon
Copy link
Member Author

ibilon commented Mar 10, 2016

In that case we could at least hide one and change the help of the other?

@nadako
Copy link
Member

nadako commented Mar 10, 2016

Not sure I understand you now :) upgrade is already hidden, for others what you propose seems good: emit a warning, maybe add a [DEPRECATED] tag to their description.

@ibilon
Copy link
Member Author

ibilon commented Mar 10, 2016

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.

@nadako
Copy link
Member

nadako commented Mar 10, 2016

Agreed!

@Simn
Copy link
Member

Simn commented Mar 10, 2016

Agreed as well!

@nadako nadako closed this as completed in 9415fdd Mar 10, 2016
@nadako
Copy link
Member

nadako commented Mar 10, 2016

I added a deprecation method in the referenced commit, we'll use it for selfupdate when it becomes redundant.

@nadako
Copy link
Member

nadako commented Mar 10, 2016

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 install in various ways. But let's not focus on it right now and implement it when we'll be finally refactoring the codebase.

nadako added a commit that referenced this issue Mar 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants