Closed schristley closed 1 year ago
Note that there is a release-1.3 branch, according to our release process which we can use for these changes, and not conflict with AIRR Schema V1.4 and ADC API V1.2
@schristley I would like to mark this as Closed? Any objections? We do not have a tag or branch that maps to the ADC API v1.1 release at the moment. Do we want to tag or create a branch? We have a branch for ADC API v1.2
v1.1 has for when clone end point was added, but this is moot now with v1.2
We kinda sorta made an ADC V1.1 release. When V1.3.1 of the schema was tagged, the ADC API spec had a 1.1.0 version. I say "kinda sorta" because the clone API didn't go through any rigorous testing, and there are some unresolved issues.
/clone/{clone_id}
entry point is potentially unusable because uniqueness criteria forclone_id
isn't defined.How do we want to handle this?
I think one thing we can do is separate ADC API version releases from AIRR schema releases. We can simply do this by having different tags for the ADC API. Because the spec points to a specific schema version, we can manage them separately. This might require some juggling by data repositories if they access both the API and Schema yaml together, but this can be alleviated if older schema versions are kept around (see #582 ).
If we decide upon this, we could technically say ADC V1.1 wasn't released yet, resolve the above issues, then tag a release.