Release candidates for all repos dependent on KERIpy 1.1.0.

[pfeairheller]

Let us know what you think

[kentbull]

I like the idea of versioning all of the following repos together for this initial release train:

• KERIpy (of course)
• KERIA (It's a big jump from 0.1.0 -unreleased- to 1.1.0, though tagging them together will help clarify compatibility for this initial release train)
• SignifyTS (starting at v1.1.0 doesn't seem like a bad idea, though I acknowledge it is a jump and there isn't a 1.0.0)
• SignifyPy (this tags along with KERIpy and KERIA and makes sense to version similarly at this point in time)

[m00sey]

I think versioning "similar" to start is all we can expect.

To Daniels point on the call, libraries might make additional updates and shouldn't require version changes in any of the others.

I see a matrix in our future of known support versions that integrate.

[m00sey]

No, I do not want to maintain it.

[iFergal]

Agree with this so that the semantic version is actually accurate, and for all of them. A bug in KERIA will require a patch bump but maybe not in keripy.

I think the major version is the only easy one to keep matched as breaking API changes will cascade down (unless there are feats in keripy that wouldn't get added to KERIA... beyond my knowledge :D)

[lenkan]

I also think semantic versioning is a good idea. However, I do not see the inherent value of forcing all projects to follow the same version. I also do not think there is a rush for bumping keria and signify-ts to v1.x.x. I think it is inevitable that some features, improvements and bug fixes in signify-ts would cause breaking changes in the near future. If we bump them to v1 too early, I think the progress would slow down in that regard.

So, from my point of view, bumping keripy to v1.1 is a good step forward, but it does not have to affect keria or signify-ts versioning at all right now. Except that keria can now use released keri pypi package. If we want to start versioning them anyway, my opinion is that they should start at v0.x.x for now.

Issues like these:

• Contact challenges missing from GET /contacts/{prefix} keria#173
• Name parameter is not needed for GET credentials by SAID endpoint keria#142

might result in semver major bumps to keria, but probably not in keripy. They're just examples, but I do think there will be more similar issues once keria starts getting used in production like environment by a wider audience.

In signify-ts, there is a lot of missing type information that would cause breaking changes when adding types to improve the usability of the library.

Analogies

I would also like to draw some analogies to other projects with similar setups. Granted, none of these are exactly the same, but I thought it would be good to have a look around for inspiration.

Lucene => Solr / Elasticsearch / Opensearch => Client libraries

Lucene is the underlying library providing full text search (keripy). Solr, Elasticsearch and Opensearch are independent projects providing "lucene as a server", (i.e. keria). Then there are a bunch of libraries out there that can communicate with these APIs.

• Servers do not follow the versioning of the underlying library.
• Official clients mostly follow the major version of the server.

RabbitMQ / ActiveMQ servers => AMQP protocol => AMQP Libraries

RabbitMQ and ActiveMQ are server applications (keria), that implement a protocol AMQP (Signify protocol). The client libraries (signify-ts, signifypy) are completely decoupled from the server using the protocol. So they each maintain their own versioning and simply support a specific version of the protocol.

[daviddm]

I agree with @lenkan regarding the versioning of packages.
An example is the npm mqtt lib.

https://www.npmjs.com/package/mqtt#important-notes-for-existing-users

mqtt@2 started to support protocol version 3 which required a major bump.
mqtt@3 started to support protocol version 5 which required a major bump.
mqtt@4 rewrote the error handling, which required a major bump.
mqtt@5 changed the signature of the client, which required a major bump.

[pfeairheller]

It was pointed out that perhaps we should be going to 2.0.0 because there are breaking changes in the database that require a migration.

Any objections?

[2byrds]

That makes sense from the did:webs reference implementation perspective. I was considering the upgrade from 1.0 to this new version to include breaking changes.

[daidoji]

I'm for versioning libraries and protocols and don't think they need to be in lockstep.

As noted above, in most distributed systems there's the protocol versions (or even profiles as time goes on) and then there are library versions that support some(all?) of those protocol versions.

As time goes on and the deployed applications/libraries gains traction, it'll be harder and harder to keep library versions sync'd if that was a suggestion we were contemplating.