Make version_0_2 the default branch and rename master to version_0_3

[widdowquinn]

Many users who install pyani v0.2.x through conda or PyPI come to GitHub for documentation, and find the default branch master, which refers to v0.3+. The CLIs are different, and this causes confusion (see #240 #238 #226 #192 #176 #171 #169 #165 etc.)

By making version_0_2 the default, we present the stable version of pyani, and the documentation that those users expect.

Renaming master to version_0_3 has a number of desirable effects, including being explicit and transparent about the purpose of the branch, and setting a precedent for branch naming when developing future versions.

When v0.3.0 becomes the stable version, we can make the version_0_3 branch the default for the repo.

[baileythegreen]

Perhaps the branch name should include 'dev' in it? I know this then means the branch name might have to be effectively changed later, but it may pre-empt some additional misunderstandings about the state of the branch code.

[widdowquinn]

I would always consider that the master branch on GitHub is the development target (even though development is carrying on with other branches). Releases/stable versions etc. get marked with tags along that branch, rather than being maintained as separate branches.

The version_0_2 branch is only really being maintained in parallel because of my slowness in getting v0.3+ out of the door, and the need to make fixes that wouldn't have shown up in the much-modified v0.3+ codebase.

The main issue here is users being confused by the documentation. We can solve that just by making version_0_2 the default on GitHub. The more I think about this, the more I think pinning the name of master to a specific version is a bad idea.

[widdowquinn]

Reading the documentation on GitHub, it looks like it doesn't matter whether I think it's a bad idea - it's the route we'll have to take.

• You can choose the default branch for a repository. The default branch is the base branch for pull requests and code commits.

I think that the benefits of transparent documentation for users outweigh my concerns.

I think we should try to:

1. tidy the branches on GitHub (and locally - I've probably got a few hanging around) that still need to resolve to master
2. switch the default on GitHub to version_0_2
3. rename master to version_0_3
4. update README.md documentation to reflect the change

Am I missing anything? What do you think?

[baileythegreen]

That last comment got buried in notifications....

I don't see a great number of branches (some active ones—mostly mine—and a few stale ones). Which would you be trying to eliminate?

If we do # 2 and # 3 in that order, they are easy to do.

I guess the only other thing would be the not you left in #250, about the config file needed to make @allcontributors work.

[widdowquinn]

I don't see a great number of branches (some active ones—mostly mine—and a few stale ones). Which would you be trying to eliminate?

There aren't many (I deleted a handful after writing that comment). I haven't decided what to do with the others.

I guess the only other thing would be the not you left in #250, about the config file needed to make @allcontributors work.

Unless there's something I've forgotten… there usually is.