ga4gh / workflow-execution-service-schemas

The WES API is a standard way to run and manage portable workflows.
Apache License 2.0
82 stars 38 forks source link

RC-v1.2.0 #208

Closed patmagee closed 1 year ago

patmagee commented 1 year ago

Motivation

This release focuses on two main themes: Observability and Scalability.

Observability: As more people have adopted WES it has become clear that the current API does not provide enough information for end users. The RunStatus and Log models have limited required keys and making actionable decisions on the information that is available is difficult without performing additional requests.

Scalability: As more implementors are looking to "productize" WES, the topic of scalability has continuously come up. Specific features of WES (such as embedded task logs) make implementing WES API a challenge, and can cause the service to break (Ie too many task cause a service to consume too much memory).

What's Changed

Additional Improvements

uniqueg commented 1 year ago

Thanks a lot for this @patmagee!

I would just like to point out that there is neither a tag nor a release for 1.1.0 yet. So I guess we should either find the commit that was supposed to represent 1.1.0, tag that and create a release (as discussed here for 1.0.1: https://github.com/ga4gh/workflow-execution-service-schemas/issues/191) or set the upcoming release associated with this PR to 1.1.0.

Of note: The workflow version indicated in branch develop is still, as of today (last update 2 hours ago), 1.0.1. See https://github.com/ga4gh/workflow-execution-service-schemas/blob/ec84aa443ba2aae6abfa01d15d505c09df8ae65e/openapi/workflow_execution_service.openapi.yaml#L5.

As @vinjana pointed out here, the 1.0.1 release didn't follow SemVer (should have been 1.1.0 instead), but that is now history. But I think one thing we could do is bump the current version in develop to 1.1.0, tag and release. Then rebase this PR against that for a 1.2.0 release.

vsmalladi commented 1 year ago

@uniqueg and @patmagee I think the intention was 1.0.1 was supposed to be 1.1.0. Thus my recommendation would be to add another taged release at the same commit as 1.0.1 and mention in the notes that this was supposed to be SemVer 1.1.0, but don't change the version in the repo. In tag release notes 1.2.0 explain the issue and why we moved to SemVer 1.2.0