[bug] recent change broke search function about mal HOT 5 CLOSED

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?

from mal.

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

from mal.

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

from mal.

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.

from mal.

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

from mal.