Feature/handle dev versions

[corriander]

Well, this is nice! I was about to write something to increment versions automagically and I stumbled on this.

Sadly my use-case* requires dev versions and release versions only (perhaps with a release candidate option somewhere down the line) and I decided to have a stab at folding the functionality in rather than reinvent this particular wheel. Let's say I now intuitively understand both a) why you haven't implemented this yet and b) PEP440 discourages various types of dev and post releases...

That said, I've given it a shot.

• I've tried to keep to your style. I did amend a couple of things but it was a very light touch.
• I've tried to logically break the change down into commits as it's turned out to be fairly extensive.
• I went for bulk tests rather than try to finesse it. I'm moderately happy now but please feel free to check them carefully as there were a few false starts and I'm not sure I've caught the edge/corner cases. I had to backtrack a few times...
• I elected to not bother dealing with a dev version of a new pre-release phase (e.g. 0.1.1a1.dev1) so that can never happen. I think. I suspect this needs an optional dev parameter everywhere and I felt I'd changed enough. next_dev() increments the pre-release everywhere, so ...a1.next_dev() jumps to ...a2.dev1
• Naming things was quite hard. Not everything had an obvious name and some things are ambiguous (e.g. "segment", "suffix" "marker"). Feel free to suggest alternatives.
• I'm not a fan of the explosion of internal module functions, but I was reluctant to break away from the pattern too much.
• I actually feel there is some support for local segments and other things perhaps solve the problem.*
• I suspect .postN releases can be handled similarly but I fear the ifs involved.
• My gut feel is that this is actually a graph problem but I wasn't going to go down that road.

Anyway, hope this is useful. I'll try not to submit and run but I'm fairly snowed under at the moment so please bear with me :)

*I'll explain my use case a little more because it might help: I stumbled on versioneer and that handles "what is the current version?" fantastically. I was looking for something in a CI Azure Pipeline that would take a version with a local segment and, under certain conditions, increment to a dev version. These changes now achieve that.

[m-vdb]

hey @corriander ! sincere apologies for not seeing your pull request earlier. Thanks a lot for the detailed write-up! I'm curious if you actually used the changes in your PR to solve your use case. If so, did it work like expected in your workflow?