Should we add a caveat in the 'Easy releases' page as per #1092 (comment) and add a new page to explain how and when to use a compiledRelease? (eg "Latest version only" (other names welcome)) That is because I think the 'Easy releases' page is already long and focuses on still publishing (but not storing) multiple releases per contracting process. If we add this new page, we will have:

• Change history (for the full versioning support)
• Easy releases (for partial versioning support)
• Latest version only (for not versioning at all)

I never liked the name "easy releases", and we don't want even more terms. There are two main decisions to make:

1. Whether to have a change history (if not, link to new page about publishing compiled releases only)
2. Whether to have incremental updates (current "change history" page) or full updates (current "easy releases" page)

There should be a new "change history" section that discusses the two decisions, and why you would choose one or the other, and then link to the appropriate example.

This structure would make the decisions that publishers need to make much clearer. The easiness of implementation isn't the most important consideration, so I'd be happy to remove that word.

and we don't want even more terms.

Agree, but I guess we still need a title for the new/replaced sections, rigth? Something like:

The new section with the approaches discussion -> "Change history"
The current "Change history" -> "Incremental updates"
"Easy releases" -> "Full updates"
The new section with the compiled release only example -> ?

Or what do you think?

Yes, and the new page can be "No change history" ?

I've drafted here the content for the new two pages (The new section with the approaches discussion -> "Change history" and The new section with the compiled release only example -> "No change history"). @duncandewhurst maybe you can take a look at it first?

@yolile I've added some comments and suggestions - happy to discuss!

Should we change https://standard.open-contracting.org/latest/en/schema/merging/#merge-routine as well? At least the first sentence that says "To create a compiled or versioned release, you must:"

I think we'll need to word a bit carefully, because if individual releases are optional, then compiled releases can be created directly. (Versioned releases, on the other hand, don't make any sense without individual releases.)

Related: #1364

Just noting that the outstanding task here is to rename some pages and update their introductory paragraphs per #1531 (review)

I think the main outstanding task is finishing #1531.