Release procedure isn't documented

[esc]

Release procedure isn't documented

[mriehl]

There's a pybuilder plugin for it if you want: https://github.com/aelgru/pybuilder_release_plugin

[esc]

@snordhausen this is still kind of missing. Currently one has to increase the version number and a new release will be automatically generated and uploaded (by internal CI). I would like to pledge for a changelog though, what do you think?

[esc]

Also, it would be good to check the version number, currently, it is:

1.2.0.post0

and I am not sure what to make of the .post0 suffix.

[schlomo]

What about automatic versioning? I also don't see the point in having A.B.C versions. Maybe A.B is enough where A represents the protocol version (which should match the protocol version of AFP) and B is just some automatically increasing number?

[esc]

So, right now the situation is snafu. Building and releasing from out TeamCity leads to the following version numbers:

1.3.1.post174

Where we now have a stale version number 1.3.1 and an automatic suffix post174 which is the build number generated by teamcity. This value is completely useless to anyone that doesn't have access to the teamcity, since it is in no way related to the source code.

I'd vote for simple commit count on master for the version number and adding relevant changes to the changelog when you do them. E.g. "as of version 345: keychain password provider can delete incorrect passwords."

I'll implement these changes soon, unless there is opposition.

[schlomo]

Yes please, I so much prefer a simple version instead of this semantic versioning stuff. We live in a continuous delivery world and should also embrace it.