Release Strategy Discussion #268
Replies: 9 comments 18 replies
-
|
From the email chain from @sshiells-scottlogic I think it is worth picking up the discussion on releases / release scheduling before the next delivery WG call? What does a release look like? Do we package anything up, or is it simply the controls and threats files produced by the security WG? If it is the latter then I support Eddie's suggestion of having milestones along the lines of "Virtual Machines 1.0" etc. Then we could use "Event" milestones to group services that we are targetting to complete for specifc events e.g. OSFF NY? We would then just use labels to identify each WG's contribution towards each release (as milestones are probably too much). We also need to decide on what versioning looks like and how we control newer/updated versions. Would it be worth using the Community Structure WG meeting this week to continue this discussion? |
Beta Was this translation helpful? Give feedback.
-
|
ref: #259 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
@sshiells-scottlogic - my thoughts on this: A release should be defined as a grouping of artifacts that will be communicated to the public. I should define any new controls, threats, and taxonomy catalogs that have been created or updated (after a PR is merged into main). What we can do is create a release that includes a high-level description of the changes for each catalog, the names of the people who contributed to it based on commit ID, and also we could include the company logos that have contributed to the cause. The idea I have in mind for versioning includes the entire project and follows SemVer standards. Here is an example flow diagram I came up with to help you all visualize what I am thinking when we onboard new services to a project:
And for any updates that are created, we'd increment the second number. For example, if the security WG adds in new controls/threats to an existing catalog, then we'd move from 1.0.0 to 1.1.0. The same is said for the Taxonomy WG. This could also include, but is not limited to, changes to policy and guidelines, etc. For minor changes, like grammatical errors or formatting issues, we'd increment the last number. So if there was a misspelling of a word that was caught, the release number would go from 1.0.0 to 1.0.1. Thoughts? I'll come back to the milestones later since I believe it'll go hand and hand with version control for our artifacts/content. I think we should try and figure that out first and then discuss milestones. |
Beta Was this translation helpful? Give feedback.
-
|
What do you have in mind for the artifacts? What is not clear to me is exactly what we are deliverying to people. Are we packaging files up and shipping them via some method, or are people simply going to come to the GitHub repo and take the files from there? |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to hear yalls response to two ideas that I'm partial to:
|
Beta Was this translation helpful? Give feedback.
-
|
I agree with both points.
1) Each service is independent. Any grouping would be arbitrary and likely delay the release of services.
2) I think as the project grows the spread of versions will be quite wide. It's not too had to see a scenario where we have version 3.6 of one control, and 1.0 of another. I can imagine people might try to sync versions (I've got 3.6 of service x, I must have 3.6 of service y).
I think incorporating the date also makes it easier to see how stale a specific service is.
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Eddie Knight ***@***.***>
Sent: Monday, July 22, 2024 5:07:30 PM
To: finos/common-cloud-controls ***@***.***>
Cc: Stevie Shiells (He/Him) ***@***.***>; Mention ***@***.***>
Subject: Re: [finos/common-cloud-controls] Release Strategy Discussion (Discussion #268)
I'd like to hear yalls response to two ideas that I'm partial to:
1. Separate versioning for each service artifacts
* For example, the Taxonomy, Controls, and Tests for Object Storage
* Increases delivery automation overhead while segmenting development lifecycle logistics into smaller chunks
* Allows for more granular attribution
1. CalVer instead of SemVer
* Even if we use a simplified CalVer, users can know how old a control set is at a glance
* (ie, Object Storage 23.07 was defined in July 2023)
—
Reply to this email directly, view it on GitHub<#268 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BDJRNBUEASHADLT5GKJM47DZNUU4FAVCNFSM6AAAAABLIMY7UOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJRGY3TMMQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
The contents of this email and any attachments are intended solely for the addressee and may contain confidential or legally privileged information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. The information may not be used or disclosed except for the purpose for which it has been sent.
Email is susceptible to data corruption, interception, unauthorised amendment, viruses, and unforeseen delays. Although Scott Logic Limited has taken reasonable precautions to avoid these situations, it cannot accept responsibility for any loss or damage sustained as a result of any of these actions and the recipient must ensure that the email (and attachments) are virus-free.
Please note, that we do not accept notification of changes to bank account details by email. This applies to notifications from or to us.
Scott Logic Limited is a limited company registered in England and Wales with registration number 05377430. Registered office address: 6th Floor, The Lumen, St James Boulevard, Newcastle Helix, Newcastle upon Tyne, NE4 5BZ . Our VAT number is 866 1051 30.
|
Beta Was this translation helpful? Give feedback.
-
|
@eddie-knight I understand your points. I do like the idea of versioning artifacts separately and treating each service independently to increase velocity and the rate at which we deliver. I don't foresee any issues with introducing automation with this approach. I'm skeptical about using CalVer for versioning the artifacts. Let's say we make 3 changes in July to a catalog for Taxonomy for Object Storage. Versioning it as Object Storage 23.07 would be confusing, especially for tracking purposes. I think it'd be best to specify the dates that they were modified. Also, @sshiells-scottlogic I am not sure how we'd be delivering artifacts to the public. I assumed that we'd just be sharing the links to the repository. @eddie-knight is there a plan to host the content with GitHub pages or something? |
Beta Was this translation helpful? Give feedback.
-
|
No plans yet. I suspect we want the controls catalogue to be available via PDF. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a particular reason(s) why we'd want them to be available via PDF over self-hosting it with Hugo or something that renders the Markdown files easily? |
Beta Was this translation helpful? Give feedback.
-
|
PDFs come to mind as that is the approach used by CIS Benchmarks. Just brainstorming. Happy to leave the decision in your hands. |
Beta Was this translation helpful? Give feedback.
-
|
I get your point around the 3 versions in one month using that format. However, given the pace of the project I'd be surprised if we'd run into that situation.
However, if we do could append an incremental version number to second and later releaes e.g.
23.7-2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Damien Burks ***@***.***>
Sent: Monday, July 22, 2024 7:32:56 PM
To: finos/common-cloud-controls ***@***.***>
Cc: Stevie Shiells (He/Him) ***@***.***>; Mention ***@***.***>
Subject: Re: [finos/common-cloud-controls] Release Strategy Discussion (Discussion #268)
Is there a particular reason(s) why we'd want them to be available via PDF over self-hosting it with Hugo or something that renders the Markdown files easily?
—
Reply to this email directly, view it on GitHub<#268 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BDJRNBUJ4WLRUACZHYGFCL3ZNVF5RAVCNFSM6AAAAABLIMY7UOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJRG44TKMI>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
The contents of this email and any attachments are intended solely for the addressee and may contain confidential or legally privileged information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. The information may not be used or disclosed except for the purpose for which it has been sent.
Email is susceptible to data corruption, interception, unauthorised amendment, viruses, and unforeseen delays. Although Scott Logic Limited has taken reasonable precautions to avoid these situations, it cannot accept responsibility for any loss or damage sustained as a result of any of these actions and the recipient must ensure that the email (and attachments) are virus-free.
Please note, that we do not accept notification of changes to bank account details by email. This applies to notifications from or to us.
Scott Logic Limited is a limited company registered in England and Wales with registration number 05377430. Registered office address: 6th Floor, The Lumen, St James Boulevard, Newcastle Helix, Newcastle upon Tyne, NE4 5BZ . Our VAT number is 866 1051 30.
|
Beta Was this translation helpful? Give feedback.
-
|
Just for the sake of discussion... CalVer comes in all the flavors of the rainbow. If we anticipate multiple releases per month (which I think would be a bad idea, but that's another discussion) we could choose YY.MM.DD in that case. |
Beta Was this translation helpful? Give feedback.
-
|
I feel like multiple releases per month will be the exception, not the rule. I would be wary adding the .DD part as standard as I think it will just add noise to 99% of the versions that isn't required.
|
Beta Was this translation helpful? Give feedback.
-
|
I think this idea. |
Beta Was this translation helpful? Give feedback.
-
|
SemVer is really all about representing backwards compatibility. Is backwards compatibility something we care about for CCC? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with this statement. We don't need to worry about backward compatibility for CCC artifacts; I'm sold on the CalVer idea. I believe it's fits the needs for this project. |
Beta Was this translation helpful? Give feedback.
-
|
Another advatnave of CalVer is that it is easy to see at a glance how recent/old a version is. E.g. if a vuneralbility is discovered in VMs in December 24 and the VM controls were versions as 24.8 it would be clear that controls wouldn't cover that vunerability. |
Beta Was this translation helpful? Give feedback.
-
|
Okay. So we're all in agreement that:
If so, then we can discuss the delivery of the artifacts. Let me know if I'm missing anything. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds right to me! Do we need to capture any of this in documentation? And are ready to mark this as the answer and close the discussion? |
Beta Was this translation helpful? Give feedback.
-
|
I am fine with marking this discussion as closed and starting the documentation process. @robmoffat @sshiells-scottlogic what do you guys think? |
Beta Was this translation helpful? Give feedback.
-
|
Bumping this up - y'all still okay with me closing this out? If so, I'll start writing the documentation to start with the versioning criteria for the project. |
Beta Was this translation helpful? Give feedback.
-
|
Sure |
Beta Was this translation helpful? Give feedback.
-
|
awesome! i'll get to work on documenting this. |
Beta Was this translation helpful? Give feedback.
-
This is a discussion post created for tracking the ideas flowing for defining a release strategy for the CCC project.
Beta Was this translation helpful? Give feedback.
All reactions