Currently, only the latest quickstarts are indexed and made available through the http://dcp.jboss.org search engine.
In JBoss Tools and JBDS, we plan on providing search and d/l access to dcp indexed quickstarts (JBDS-3273)

If JBDS 9 always displays results for the latest quickstarts (currently EAP 6.x), hypothetically, next year, we risk displaying EAP7 quickstarts, while EAP7 won't be supported by JBDS 9 (we'd have to wait JBDS 10). IIRC each JBDS version is supported for 7 years. So we need to guarantee the search results for quickstarts stay relevant over the years.

My understanding is indexing old quickstart versions would slow the jboss.org website build down. I think all is needed is for each build to not override the previous major release indexes. dcp queries on the website would just need to add a new constraint to only retrieve results for the last release.

Design

I think we can do this by:

1. Refactor the quickstart indexing code to be able to switch to older git tags and index those too. Or, each version of the quickstarts could be handled as a separate checkout, but pointing to a different version. This would be cumbersome for many versions, but simple for few versions.
2. Update the document schema for quickstarts in the DCP to understand versioning (Which I think it does already). Then create a new document for every version, using a field to differentiate them.
3. Optionally, we could separate out the indexing of old quickstarts from the main site build as this process could be time-consuming.
4. Update all queries that search for quickstarts, such that they understand the new versioning scheme. We also need to check that no other third parties are relying on the current structure.
5. Ensure Awestruct only creates pages for the quickstarts that need to be displayed on the RHD site

Cautionary notes:
1. It seems like the structure of these DCP documents will become a public API that we need to support for the duration of the JBDS support period. This could cause problems if we don't architect the versioning correctly from the start, as essentially we'll be stuck with the format for many years.
2. We need to make sure that we don't make an architectural decision here that conflicts with our requirements to display old versions of quickstarts on the site.