ASVS v5.0 release checklist - rough workings

[tghosth]

We need to organize and also identify dependencies/order of performance.

Any other items you can think of @elarlang ?

Task list:

Finalise unordered draft:

• Close all requirement issues.
• Change all levels.
  • Change levels to a number rather than tick boxes? (Level to numeric field #2560)
  • Need a script to update this in GitHub from Google Sheets and also update the tags.
  • This is almost complete manually, as tracked in Level changes for new level definitions #2690
• must vs should (for each requirement - the usage of "must vs should" in the main condition of the requirement #2554)

Reordering document:

• Covered by Informative list of tasks and dependencies related to mapping and requirement (re)numbering #2456
  • Re-ordering and re-numeration is done, some "just before the release" clean-up tasks to do

Prepare RC1:

• Fix export scripts for new format
  • Include backwards compatible export formats? For example that makes levels back to tick boxes
• Chapter text (including Clarify intro to "V7 Error Handling and Logging" #1132)
• Update other initial text
  • Include better explanation of what is in Level 1
• Update Glossary
• Grammar and terminology (lowercase vs uppercase grammar (original: 6.2.1 causes capitalization inconsistency) #1875, Fix backend/back-end terminology #2390)
• Announce rc1, need to consider what feedback will and won't be accepted?

Final release:

• Review and action RC1 feedback
• Add release strategy to document (a promise to users what is patch release and we don't do breaking changes into it)
• Create a release and release tag in GitHub
• Update readme
• Update translation instructions
• Write requirements scope explanations
• Update contributors information and working group

Post release:

• Prepare publicity on social and slack
• Update public website

[elarlang]

A lot of it is duplicate of #2456

Change levels to a number rather than tick boxes?

I think we have discussed and proposed it somewhere, numeric level should be more clear and easier to process.

edit: I opened a new separate issue for that: #2560

Remove cwe mappings. Leave a blank space for cre

Any mapping data should not be part of the releasable content. It can be in a separate mapping file to be "living" and by principle, it should be stored (only) in the OpenCRE side.

It is question of presentation layer, how to use and apply the mapping from OpenCRE.

Announce rc1, we will only be accepting requirement wording changes but not new requirements, not level changes, not reordering?

I don't find this limitation reasonable - this is basically the first moment we make noise and with the goal to get feedback. I would take all the feedback and make changes if we feel that we need to.

Maybe with a more clear steps for:

• A clear definition for level 1 - at the moment many throw opinions what should belong there without knowing, what it is
• Defined release strategy - a promise to users what is patch release and we don't do breaking changes into it

[tghosth]

I made some changes to the first comment.

[elarlang]

I prefer this list to be de-duplicated from #2560 - the scope here should be more general, in #2560 are technical steps to have mapping and re-organizing the structure.

[tghosth]

@elarlang is this better?