[bug] recent change broke search function

[bradenbest]

Looks like the fix to #88 caused a different bug. Any time I attempt to search for something...well, this happens:

$ mal search cat\ soup
Traceback (most recent call last):
  File "/usr/local/bin/mal", line 9, in <module>
    load_entry_point('mal==0.4.0', 'console_scripts', 'mal')()
  File "/usr/local/lib/python3.5/dist-packages/mal-0.4.0-py3.5.egg/mal/cli.py", line 192, in main
    args.func(mal_api, args)
  File "/usr/local/lib/python3.5/dist-packages/mal-0.4.0-py3.5.egg/mal/commands.py", line 25, in
search
    core.search(mal, args.anime_regex.lower(), full=args.extend)
AttributeError: 'Namespace' object has no attribute 'anime_regex'

$ mal search nichijou
Traceback (most recent call last):
  File "/usr/local/bin/mal", line 9, in <module>
    load_entry_point('mal==0.4.0', 'console_scripts', 'mal')()
  File "/usr/local/lib/python3.5/dist-packages/mal-0.4.0-py3.5.egg/mal/cli.py", line 192, in main
    args.func(mal_api, args)
  File "/usr/local/lib/python3.5/dist-packages/mal-0.4.0-py3.5.egg/mal/commands.py", line 25, in
search
    core.search(mal, args.anime_regex.lower(), full=args.extend)
AttributeError: 'Namespace' object has no attribute 'anime_regex'

filter's fine, though.

$ mal filter nichijou
Matched 6 items:
1: Nichijou: Original Jikai Yokoku
   Completed at 14/25 episodes with score 6

2: Danshi Koukousei no Nichijou
   Completed at 12/12 episodes with score 10

3: Danshi Koukousei no Nichijou Specials
   Completed at 6/6 episodes with score 9

4: Nichijou: Nichijou no 0-wa
   Completed at 1/1 episodes with score 9

5: Nichijou
   Completed at 26/26 episodes with score 10

6: Monster Musume no Iru Nichijou
   Watching at 1/12 episodes with score -

It expects the token, "anime_regex", but is getting "anime_title" instead. Looks like while the documentation was updated, the code that relies upon the internal symbols was not.

[ryukinix]

Sucks. I forgot a thing. I'll fix that now.

[ryukinix]

Take a look into #91 and try update to the last version.

[bradenbest]

Nice! I will never understand continuous-integration, but that was a quick fix. I notice you're forgetting to increment your patch number as per semver, though, which is making it hard to tell if I actually got the new version installed without testing the fix myself. For bugfixes and really minor changes, the patch number should be incremented, e.g. v0.4.1.

Just something to make it easier to differentiate, and provide some reassurance that the user didn't screw up the installation.

[ryukinix]

Yes, actually we bunch that in the past a new version each merge on the master, taking the development first on dev branch, testing it a lot, get new stuff and publish a new version on master attached to a new git-tag/github-release.

For some historical reason, we dropped that and semantic versioning here is just used as OFFICIAL release as you can look at https://github.com/ryukinix/mal/releases

In another words, you are using a not official version, not official release, just by conveniance dropped on the master branch for easy install on development. For all sake usage, you should just get a release listed in the link above.

v0.4.0 was not released yet

[bradenbest]

I would actually argue that it's important to keep the versions up-to-date in development as well.

Hear me out...

What if you have to make a rollback, for example? It would be much easier to roll back from v0.4.46 to v0.4.37, than scroll through countless commits that all have the version number v0.4. What if you're not the only developer on the project? How are you going to tell the other guys which commit to roll back to when there are forty-six different versions all named v0.4 in this hypothetical scenario? It may seem silly, but when you're testing and editing, and you aren't sure which exact version you're using, it becomes a real pain in the ass. Whereas if you are in a commit titled v0.4.37, you know you're in the right one without having to compare commit signatures and double-check every last detail. Sure, git will probably handle this, making it a not-very-likely scenario, but the extra touch surely makes things easier, yeah?

And if you're wanting to distinguish between development and release versions, it's enough to just add "-release" to the end, e.g. v0.4-release, or to put "-dev" on development versions, i.e. v0.4.37-rc1, v0.4.46-dev, etc. Then your release can be either v0.4.37 or v0.4.

I mean, at the end of the day, it's your project; I'm just trying to suggest good practices. The way I see it, if you're willing to go as far as unit-testing, CI, and generous use of branches, what do you have to lose by putting that extra bit of diligence in your versioning?