Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ERSSUP-63215]-[]-[R4 Directory Structure]-[RG] #389

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

RajaGovindharaj16
Copy link
Contributor

Summary

  • Routine Change
  • ❗ Breaking Change
  • 🤖 Operational or Infrastructure Change
  • ✨ New Feature
  • ⚠️ Potential issues that might be caused by this change

Add any other relevant notes or explanations here. Remove this line if you have nothing to add.

Reviews Required

  • Dev
  • Test
  • Tech Author
  • Product Owner

Review Checklist

ℹ️ This section is to be filled in by the reviewer.

  • I have reviewed the changes in this PR and they fill all or part of the acceptance criteria of the ticket, and the code is in a mergeable state.
  • If there were infrastructure, operational, or build changes, I have made sure there is sufficient evidence that the changes will work.
  • I have ensured the changelog has been updated by the submitter, if necessary.

@RajaGovindharaj16 RajaGovindharaj16 force-pushed the feature/ERSSUP-63215 branch 4 times, most recently from 0c49029 to 428206b Compare July 28, 2022 15:31
@@ -0,0 +1,13 @@
type: object
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and specification/components/schemas/identifiers/R4_Organisation.yaml (which has been renamed in this PR) are identical. I wonder if it's worth having a directory for OAS that is common between FHIR versions, like /components/common? I think splitting the repo by fhir version will inevitably lead into code duplication, but maybe we can avoid some?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@francisco-videira-nhs I initially thought the same, But we are keeping the duplication code for each version in the core. So I kept to each version on it's own file. So it will be easy when STU3 is deprecated. Will consider to have a common.

Copy link
Contributor

@francisco-videira-nhs francisco-videira-nhs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a comment about avoiding code duplication between fhir directories, but otherwise it looks good to me.

@RajaGovindharaj16
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@RajaGovindharaj16
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -0,0 +1,23 @@
{
Copy link
Contributor

@francisco-videira-nhs francisco-videira-nhs Aug 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for traceability, as stated in the STU3 PR, we don't commit these examples to git. During make publish they copied from the sandbox, so the directory specification/components/r4/examples/ should be added to .gitignore

@strutt strutt added the dependencies Pull requests that update a dependency file label Oct 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants