CTA / Repository / Release (or Un-release) a version

[paulsonder]

As a User, I want to be able to Release a Version of a Repository to allow consumers of its contents to understand the point in time it was released and why and so they are able to review the changes compared to previous releases.

Acceptance criteria

Entry points

1. User clicks 'Mark as Released' / 'Mark as unreleased' from menu in the Repository header
2. User confirms action in dialog
3. The Version is visually flagged as Released or Unreleased in the UI
4. Any release notes should be included in the Overview tab

Design docs

Menu and Release / Un-release item

Released Chip in the summary panel

Versions are indicated as released or not in the Version menu

[paulsonder]

@jamlung-ri Ready for your review!

[jamlung-ri]

@paulsonder In a visual sense, I like what I'm seeing, but there is a slight FHIR-related thing I was wondering about here. Our Released/Unreleased status is pretty similar to FHIR's Status attribute, which can be set as one of these: "draft | active | retired | unknown"

Do you think your design would be conducive to us making changes in the future? For example, if we went from using a Released/Unreleased model to using FHIR's Status model, do you think this would impact the designs too heavily? If the impact of that change would be manageable, then I think this is good to go. What do you think?

[paynejd]

OCL already implements the FHIR status attribute -- should we just make it live?

…

On Wed, Dec 11, 2024 at 11:20 AM Joseph Amlung ***@***.***> wrote: @paulsonder <https://github.com/paulsonder> In a visual sense, I like what I'm seeing, but there is a slight FHIR-related thing I was wondering about here. Our Released/Unreleased status is pretty similar to FHIR's Status <http://hl7.org/fhir/R4B/codesystem-definitions.html#CodeSystem.status> attribute, which can be set as one of these: "draft | active | retired | unknown" Do you think your design would be conducive to us making changes in the future? For example, if we went from using a Released/Unreleased model to using FHIR's Status model, do you think this would impact the designs too heavily? If the impact of that change would be manageable, then I think this is good to go. What do you think? — Reply to this email directly, view it on GitHub <#1981 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJCOOMSAUEO2ZYDKQTXI432FBQ6FAVCNFSM6AAAAABSNRGZOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZWGQ2TKMZSGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jamlung-ri]

@snyaggarwal Would you be ready for that? Is there any data migration needed to make it live? I would say v3 is the time to do it, if so. :)

[paulsonder]

@paulsonder In a visual sense, I like what I'm seeing, but there is a slight FHIR-related thing I was wondering about here. Our Released/Unreleased status is pretty similar to FHIR's Status attribute, which can be set as one of these: "draft | active | retired | unknown"

Do you think your design would be conducive to us making changes in the future? For example, if we went from using a Released/Unreleased model to using FHIR's Status model, do you think this would impact the designs too heavily? If the impact of that change would be manageable, then I think this is good to go. What do you think?

I think the design is flexible enough. Are you thinking we would update the OCL release status to align it with FHIR so OCL 'legacy' and FHIR repo's have a consistent set of possible status values? Or would we want to show both?