Increment version to 0.4.0 to reflect breaking change.

[r24mille]

Commits 22323c6, 79464e1, and fa7524c remove the get_lmp(...) method from BaseClient and increment the version to 0.3.20. This is a backwards-incompatible change which we should give a greater indication of via the package version number.

The industry conventions of semantic versioning (http://semver.org) suggest that the first version number position should be incremented for backward-incompatible API changes. That would mean pyiso should be incremented to 1.0.0. That feels a bit odd, so I suggest that we at least increment the version number to 0.4.0,which is reflected in this commit.

Also, we should clean out old pull requests and issues that reference LMP, since we no longer wish to include that functionality. We can do that using GitHub's issue keywords to close those issues, since they will not be fixed: closes #26, closes #22, closes #162, and closes #159. It would also close these pull requests: closes #52 and closes #106.

[coveralls]

Coverage remained the same at 54.555% when pulling 57cbf9901ebac5906620b6195a568b65406d28f8 on r24mille:increment_version_4 into fa7524c1c83a1768ee01dbcfae0a52b0d951723f on WattTime:master.

[coveralls]

Coverage remained the same at 56.614% when pulling 1ec61b123a88dfc48a7fbf82b065c8ffbb075529 on r24mille:increment_version_4 into 52a8b5590bbc31f670b3574b254ad34cfa39289a on WattTime:master.

[ajdonnison]

It seems that doing it with the command line allows you to get the commits in but it doesn't close the PR. So if you don't see an issue, can we close this (as the commits are now in master)? Or at least rebase off master and try again?

[r24mille]

Well, merging in the pull request via GitHub's client interface allows the issue keywords I set up to trigger. Just closing the pull request won't trigger them.

What's the rationale behind squash commits via command line rather than working with community contributions (like this and others) through GitHub's web interface or client?

[ajdonnison]

I'm more used to a rebase workflow, and in this case simply tried that to see if I could get past the conflict. It was only partially successful as I forgot to add a commit message to close this - the perils of doing git before coffee, I guess. I prefer squash and a combined commit message than individual commits simply to keep the history cleaner, but I am not wedded to one approach or another. Basically anything that works and doesn't cause contributors to get frustrated or confused is fine by me. I don't mind if it is only me being frustrated and confused :)

[r24mille]

OK, 0a550dc corrects the README to reflect the current state of things. It should also conveniently correct the merge button issues we're currently experiencing.

Regarding the GitHub Flow merge vs. rebase workflow... I've never worked in a rebase workflow so I can't speak to its strengths. I've only ever worked with a gitflow workflow and a GitHub Flow workflow. If I can speak in favour of GitHub Flow for a few reasons:

• Community interactions via pull requests gives signs-of-life to the repository. That's something I look for when considering which projects to commit to. As an example, with PR #169 I intentionally branched off of @emunsing's work so that he could get credit for uncovering the initial problem in PR #112. I was basically just putting polish on his work from our discussion in PR #112. The rebase trashed his commit in the history and made it look like its my contribution (which it really wasn't).
• As a contributor, I'm actually running 4-5 parallel development branches https://github.com/r24mille/pyiso/branches Since the commit IDs change, I can't tell which of my branches have been merged in easily or not. I've been having to go look at WattTime's closed PRs, match it to the branch name I gave, and manually delete my branches. Makes things a bit more difficult to track as a contributor. For example, there's no way to quickly tell that my 128_yukon_energy branch has been merged, even though that happened yesterday.
• Some people contribute publicly on GitHub to improve their resume or for other vanity reasons (and that's OK). My ~100 commits of regular contributions to WattTime did get squashed into 4 commits. I'm trying not to be too sensitive to it, but I did weep a single, very vain tear on the inside :p

[ajdonnison]

These are all extremely good points you make, and I take them to heart. Using the web interface or not shouldn't make any difference, the main problem was that I chose to squash the commits, which, as you rightly point out, is not fair on you or other contributors who expect to see all of their commits in the history. In general squash and rebase work best when it is done by the contributor, not some interfering busybody who thinks they know best (and yes, I'm referring to myself here).

From here on in I'll make sure I don't succumb to the temptation to follow old habits and instead follow a more community-minded approach. I can only offer my sincerest apologies for the confusion, and for the single tear, Vain or not it is not something I want to see in people like yourself who have done so much for the project.

[coveralls]

Coverage remained the same at 57.402% when pulling 0a550dcb5783011555dc260781272525e6988350 on r24mille:increment_version_4 into 31e1fc2b4539694398f167bb827a2e590136f7d8 on WattTime:master.