idea - using Sites instead of Translations to manage versions of Wagtail

[lb-]

I would like to put an idea out there but fully understand if this is not practical for the current GSoC timeline.

---

At the moment, my understanding is that we are leveraging the translations system for multiple linked 'copies' of a page for both languages and for Wagtail versions.

This gives us the benefits of easier transition between old/new, easier 'starting' of a new version and also it means we can leave the current pages if the UI has not changed.

However it leads to a potential url path structure that could cause problems long term I think. Where we may have multiple versions in the instance of multiple pages. There is no '4.0' path in the url.

Proposal - sites for Wagtail versions & Collections for images/docs

I think it may be more practical to have a new Site created for each new non-patch Wagtail version. The new site would copy deeply the previous version's site and be served at a fully isolated path.

Either guide.4-0.wagtail.org or potentially guide.wagtail.org/4.0/.

There would also be a 'next' for WIP future Wagtail changes that are only visible in the main branch.

This gives us the following benefits.

• more explicit seperations of releases
• ability to have a seperate site tree for each version more easily
• easier to scrape / or provide an export of content for a specific version
• using the SiteSettings system for small UI / Layout changes that may adjust over time
• the landing page can be a seperate Site also - not related a specific version
• easier to manage in the UI over time as there could be lots of versions

Additionally I think we could then provide a nice mechanism for images / screenshots that change over time via the collection system. Each site would have a distinct collection created and only images for the sites'matched collection would be available in the picker.

For legacy versions of Wagtail that are still in the system, these can be archived/frozen by a process that could either lock all pages in the site or lock out all non-super users from accessing those.

[allcaps]

The main benefit of 'translations as versions' is that pages with the same topic are 'grouped'. We have a language chooser to jump to other version with the same topic. Similar to the version chooser in RTD. If we decide to have a multi-site, we lose this grouping and the ability to switch. Sure, we can reimplement a similar feature jumping between domains, but that feels like reimplementing translations...

Multi-site and multi-language are similar: Both have multiple home pages under the root node. The differences are site objects (for multi-site) and i18n_patterns + middleware (for multi-language). So the request takes a slightly different route, but the data model is similar. I think all your suggestions can also be realised in a multi-lingual setup.

[lb-]

Thanks for the response Coen - sorry for the random brain dump from afar.

No further feedback from me.