Is it worth differentiating between "deployments" and "releases"?

[bethesque]

Thinking about the pacts between the Pact Broker and the Pact Broker Client gem, (or any API with multiple versions of an API client out in the wild), "deployment" and "undeployment" of the clients doesn't seem like the right terminology.

At the moment we have (or will have, when I release it):

• record-deployment --pacticipant Foo --version 1 --to-environment prod
• record-undeployment --pacticipant Foo --version 1 --from-environment prod.
• and a selector currentlyDeployed: true

With a mobile client, you can't ever "undeploy", but you could "end support". Wondering if there's any benefit to be gained from having:

• record-release --pacticipant Foo --version 1 --to-environment prod
• end-support --pacticipant Foo --version 1 --environment prod or record-release-support-ended ...
• and a selector currentlySupported: true

Would having different terminology for deployments/releases make it easier or harder to understand?

[TimothyJones]

I think it would be more intuitive if the terms in the second example were consistent with the *-deployment ones - eg:

1. record-support, end-support, currentlySupported
   or
2. record-release end-release, currentlyReleased.

I think I prefer the support terminology.

Do the deployments/releases behave differently, or are they synonyms?

[bethesque]

record-undeployment sets the currentlyDeployed boolean of the DeployedVersion (which is the version/environment/time period object) to false, and sets its undeployedAt date to the current date.

I would imagine a 'release' would be exactly the same, except it would have currentlySupported: true|false instead of currentlyDeployed. There also wouldn't be the concept of "replacing a previous deployed version" with a release, as you would with a deployment.

[bethesque]

I don't have strong opinions on the naming for the release commands, more wondering whether or not making a distinction between the two is helpful because it maps more closely to the domain language of supporting client libraries, or confusing because there are now two ways of doing a pretty similar thing.

[TimothyJones]

I like making the distinction, because it makes it clear that these commands would be appropriate for the use case / have been thought about.

I wonder whether record-deployment to prod should automatically undeploy the previous version, but the release shouldn't?

[bethesque]

Yes. That's exactly what I was thinking. By default, the record-deployment marks the previous deployed version as undeployed, but there's a --no-replaced-previous-deployed-version flag available to disable that. The equivalent command for the release would not mark the previous release as unsupported by default. It's most likely that the support would be dropped for the oldest version, not the previous one, and the version would need to be specified explicitly (or perhaps by date, eg. "drop support for any version older than 2 years").

[TimothyJones]

Yeah, that makes sense. For mobile, it might be a platform compatibility thing - you might be like "drop support for anything that doesn't run on iOS version X". I'm not really up with how mobile deployment works, though. I'll ping some people who know it better than me.