How to start versioning a composer package?

Question

I'm starting to develop a package that i'd like to open source and use in future projects. I don't understand the proper steps to get this started though.

I've just created the repository on github and here is my composer.json

{
    "name": "ProgrammingAreHard/Arbiter",
    "license": "MIT",
    "type": "library",
    "description": "Convenience library to manipulate Symfony ACL's",
    "authors": [
        {
            "name": "David Adams",
            "email": "[email protected]"
        }
    ],
    "autoload": {
        "psr-0": {
            "ProgrammingAreHard\\Arbiter": "src/"
        }
    },
    "require": {
        "php": ">=5.3.3"
    },
    "require-dev": {
        "symfony/security": "2.4.*",
        "phpunit/phpunit": "~4.0"
    },
    "minimum-stability": "dev",
    "target-dir": "ProgrammingAreHard/Arbiter",
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

I'm having a tough time wrapping my head around versioning though. I haven't made any git tags. I've put the branch-alias on just because i hear that it's a good practice. I'm not sure 1.0.x-dev is what should be there right now.

What should i do at this point? I'm not at a point where i'm comfortable with a 1.0 version. Should i create a lightweight or annotated git tag at something like "v0.1.0" immediately or wait until i'm at a point where it's fully functional?

What should i be doing so that it's not a headache later?

I'm assuming composer uses git tags for versioning(?)

Answer 1

In doubt (since you can chose any policy you want), you can refer to semantic versioning 2.0

Major version zero (0.y.z) is for initial development. Anything may change at any time.
The public API should not be considered stable.

As long as your public API can change, stay in 0.x.y.