git master/branch structure about pvlib-python HOT 4 CLOSED

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.

from pvlib-python.

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....

from pvlib-python.

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)!

from pvlib-python.

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

from pvlib-python.