search

neubig / travatar

This is a repository for the Travatar forest-to-string translation decoder
GNU Lesser General Public License v3.0
28 stars 11 forks source link

Command line options do not follow POSIX guideline #38

Open odashi opened 8 years ago

odashi commented 8 years ago

Currently, all utilities in Travatar use command line options with one-hyphen style like -foobar, but this format is out of POSIX guideline and also GNU's claim: https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html

We had better replace all command line options to double-hyphen style (--foobar) and may also be better to provide one-character format (-f) for frequently-used options for user's convenience. One idea is using Boost.ProgramOptions, which can generate POSIX-compatible interface.

neubig commented 8 years ago

I think this is a good idea! If you have time go ahead and incorporate it. (We'll have to change the documentation and scripts as well)

odashi commented 8 years ago

OK I will do soon.

philip30 commented 8 years ago

Is there anyway to maintain the backward compatibility by doing this? I think it is not good idea to break the scripts that use the previous option.

odashi commented 8 years ago

I also think that... this change should be included to the "next release," but Travatar has no release tags currently. This change breaks backward compatibility, so we should handle that both current stable version and future commits are definitely different. To do so, we should:

  1. Put a release tag on GitHub for current stable commit (i.e. we make the "first release") to keep convenience for older versions' users.
  2. Fix any download shortcuts to address the "first release." (this means the HEAD of this repos turns unofficial)
  3. Make branch and fix them.
  4. Add version guidance, and updating guidance to official support page and documentations in this repos.
philip30 commented 8 years ago

For the release and further development, actually I would like to suggest to use "git flow". It is simple, concise, and clear. The overview of the engineering process is shown in this cheat sheet. "http://danielkummer.github.io/git-flow-cheatsheet/"

The process would look like:

  1. master -> The head of master is the latest release
  2. develop -> All the developments are committed here

git flow supports a release mechanism with ease, we can just type "git flow release start 1.0.0" to start the release of travatar of version 1.0.0 (and make a tag of 1.0.0).

Please tell me what you guys think about this.

neubig commented 8 years ago

Sounds good to me! It seems simple enough, so maybe we can try it out for a little while and if there are any problems we can think about a different way later.

On Wed, Feb 24, 2016 at 11:06 AM, Philip Arthur notifications@github.com wrote:

For the release and further development, actually I would like to suggest to use "git flow". It is simple, concise, and clear. The overview of the engineering process is shown in this cheat sheet. " http://danielkummer.github.io/git-flow-cheatsheet/"

The process would look like:

  1. master -> The head of master is the latest release
  2. develop -> All the developments are committed here

git flow supports a release mechanism with ease, we can just type "git flow release start 1.0.0" to start the release of travatar of version 1.0.0 (and make a tag of 1.0.0).

Please tell me what you guys think about this.

— Reply to this email directly or view it on GitHub https://github.com/neubig/travatar/issues/38#issuecomment-188012570.

odashi commented 8 years ago

LGTM too.

philip30 commented 8 years ago

Hi Everyone,

I have just created a "develop" branch for Travatar and added a v1.0.0 release to the repository. From now on, I think it is better to do development on develop branch, and we can conclude some milestone of development as new release and merge it to the master branch.

Thanks!