git master/branch structure

[wholmgren]

Now that we have our first release we need to make a decision regarding how to handle the git tree. This was discussed a bit in Sandia-Labs/PVLIB_Python/issues/33, and @uvchik brought it up in #15.

I always look first to copy IPython and/or pandas. The ipython system is roughly:

• master should be the next major release. Now that 0.1 is on pypi, this would mean that the master version should be updated to something like 0.2.0dev. See release.py
• Branches should be created for any maintenance releases. So, if we're going to bother with a 0.1.1 release then it should be developed in a 0.1.x branch.

So far as I can tell, pandas just keeps bumping the version number by 0.0.1 or 0.1 according to the scope of whatever has been merged. Maybe they let some bigger PRs rot for awhile if they're trying to focus on a maintenance release.

In principle I like the IPython system, but in practice, I think that we should go with the pandas system at this early stage. The IPython system probably makes more sense if/when we get to 1.0 and 2.0 releases. However, I don't care too much about this (we just need a decision so that we can update the version file), and I am especially willing to go with the IPython system if somebody else volunteers to be the main administrator of the maintenance releases and development.

Whatever we decide on should be added to the Development wiki.

[bmu]

I would prefer the pandas system (simply let master be the next release), because it is the most easiest. Pandas tags release candidates if they made bigger changes, before releasing the next major version. But I think up to now, this is not necessary for pvlib.

If we do so, the only thing we need to do after a release is to change __version__ in pvlib.version to <<next_release>>.dev (0.2.dev in the actual case), as far as I can see.

[uvchik]

For now, it might be enough to go on with the master branch and a few weeks before the release we branch a new 0.2-branch from the actual commit. Then we go on with developing the master. From this time bug fixes will be merged into the "master" and the "0.2" branch but new features will only be merged into the master branch. So we can make sure that the new version is stable. Then we release the 0.2 and go on with the master until we branch a 0.3 branch a few weeks before the 0.3 release, and so on....

[bmu]

Pandas has a much broader user base and uses a simpler workflow, so I don't think we need stable branches. We are free to create / tag a point release in case of a critical bug and as long as enhancements / new features are described in the release notes nothing is wrong, if they are included.

It is much easier to contribute if we use the simpler workflow (have a look at matplotlib, they have lots of branches, but I don't think it makes life easier)!

[wholmgren]

For now, we're going to follow the Pandas model, but we may revisit this discussion when pvlib graduates to 1.0.