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:

• [x] Close all requirement issues.
• [x] Change all levels.
  • [x] Change levels to a number rather than tick boxes? (#2560)
  • ~~Need a script to update this in GitHub from Google Sheets and also update the tags.~~
  • [x] This is almost complete manually, as tracked in #2690
• [x] must vs should (#2554)

Reordering document:

• [x] Covered by #2456
  • Re-ordering and re-numeration is done, some "just before the release" clean-up tasks to do

Prepare RC1:

• [x] Fix export scripts for new format - Include backwards compatible export formats? For example that makes levels back to tick boxes #3136
• [x] Chapter text (including #1132)
• [x] Update other initial text - Include better explanation of what is in Level 1 #3135, #3134
• [x] Fix things that are not in 3rd person (we, you) #2802
• [x] Check references? #2783
• [x] Update Glossary (#2201)
• [x] Grammar and terminology (#3013, #2390)
• [x] Announce rc1, need to consider what feedback will and won't be accepted?

Final release:

• [x] Review and action RC1 feedback
• [x] Add release strategy to document (a promise to users what is patch release and we don't do breaking changes into it)
• [x] Create a release and release tag in GitHub
• [x] Update readme
  • [x] We don't look translations for v4.n anymore
  • [x] Align list (order) of project leaders with v5.0.0 Frontispiece
  • [x] Align list of working group members with v5.0.0 Frontispiece
  • [x] Announce the release date / release
• [x] Update contributors information and working group

Post release:

• [x] Prepare publicity on social and slack
• [x] Update public website
• [x] Update translation instructions
• [ ] Write requirements scope explanations

[elarlang]

A lot of it is duplicate of https://github.com/OWASP/ASVS/issues/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?

[tghosth]

@elarlang anything else needed here? There is one item that isn't ticked