Decide on a Versioning Scheme (Are we "1.0" yet?)

[alexw91]

s2n server side code is rock solid, but the client side code is still being worked on. Once the Client Side is finished and we are getting close to a "1.0" release, we should decide on a versioning scheme, and decide what version we are in that scheme.

[colmmacc]

Just throwing in that AWS we often use dates for our versions. E.g. an API might be 2017-03-10, because that's the day we wrote the model. Or sometimes we use the launch day, if we can predict it well enough.

[raycoll]

A date is simple, but it doesn't express anything about API/ABI changes, nor does it express the scale of changes across versions. I wonder if we still need to use something like semver to help users become comfortable depending on libs2n.

[raycoll]

My .02 on a "1.0" is: Not until our client mode is production ready.

[ashemedai]

If I can chime in as someone who did/does packaging for FreeBSD: semver is vastly more appreciated over date-based versions.

[madolson]

This would be really nice to have before a 1.0. We are attempting to add s2n (client and server) to Redis as an optional build configuration. We believe the code is pretty stable now, and would like to avoid any backwards incompatible or broken changes.

[colmmacc]

We talked about this at our planning meeting and I think we're pretty much able to go 1.0 now. How about we do it on May 1st? It'll be easy to remember.

[alexw91]

Just annotated our latest commit with version "v0.9.0": https://github.com/awslabs/s2n/tree/v0.9.0

We'll probably be moving to a 1.0 version soon.