Snapshots from trunk

Status: brainstorming phase. We could start after 26.1 or 26.2

The Tiki community has a well established lifecycle. It is, overall, the best lifecycle for our context and resources.

However, even the best option has tradeoffs:

• The Tiki 8 months release cycle can lead to a long time for a feedback loop. By the time a non-backported commit is used in production, the developer is very likely working on something else
• In an ideal world, trunk/master would be releasable at any time. In practice, this is not possible and in certain cases, this would be counter-productive. Sometimes, you just need to "burn the boats" and merge a risky / disruptive merge request in trunk/master and "we'll deal with the issues if/when they arise". Thus, running a site from a daily update from trunk/master is always going to be a bumpy ride.

Proposal

• Have periodical snapshots from trunk/master that are known to be stable enough to dogfood.
• These snapshots will have additional tests that are too slow for the CI (that runs at each commit)
  • End to end testing
  • Tools to evaluation website performance and detect performance regressions.

Naming convention

Some options:

• Tiki27 Alpha1, Tiki27 Alpha2, etc. in which case the 1st release after we branch is Beta1 Not good because alpha gives the feeling it will get more and more stable, since Beta is next)
• Tiki27 snapshot1, Tiki27 snapshot2, etc.
• Tiki27 snapshot2023-09-12, Tiki27 snapshot2023-09-20, etc.
• Other ideas?

Where to use

These are not destined for end users for production sites, but rather for projects where members are actively participating to the Tiki community. They can also be suitable for testing new features not yet available in a stable branch.

• It would be combined with Using GlitchTip as part of the Tiki development process
• Dogfood for certain community sites such as https://themes.tiki.org and https://dev.tiki.org (But we'll keep tiki.org and https://doc.tiki.org on latest stable and profiles.tiki.org on latest LTS so we dogfood a diversity of branches
• We should add a specific chatroom to report issues with these sites (Dear visitor, these sites are using snapshot code from trunk, please click here to chat with a developer and report any issue)
• Client projects that are to be launched in a few months, and we'd like to use the latest code base.

Mechanics

• This would be a Git tag

When to tag

• When trunk/master is stable and there are no known major issues or risky work
• Before any major or risky work. Ex.: increasing requirements from PHP 7.4 to 8.1

When not to tag

• Just after a database schema change (because it makes it tricky / risky to revert)

Tagging frequency

• Every 7-10 days?
• Every 25-30 day?

The frequency may be quite different for a post-LTS release like Tiki25 with a lot of innovation va Tiki27 which is more a refinement release.

Related developments

• Tiki Manager
  • Add a way to upgrade/downgrade to a specific tag
  • Add a way to automatically update sites to latest snapshot tags

What happens if a major issue happens in an snapshot?

• Statistically, this will happen.
• Given the regression was introduced recently, it will be easy to figure out which commit caused it and alert the developer
• Normally, it should be fixed quickly and a new tag issued.
• Users can wait for this update, or revert to previous tag if
  • there has been no Database Schema Upgrade since the last tag
  • there has been a Database Schema Upgrade but that doesn't affect the site. This will need to be evaluated on a case by case basis.

Warnings for anyone using these

• These are not stable versions and there will be bugs, including a risk of data loss
• This is a test project, and there is no commitment for the frequency
• You should be using from Git so you can easily update later to a stable branch
• Security patches should be included promptly (because security patches go to trunk before being backported to the stable branches). However, it could happen that some security patches are in a stable release but not yet in an snapshot release.

Benefits

• It becomes easier for testing and documenting new features sooner
• It is easier to check if a bug is already fixed in trunk/master
• It will keep trunk/master more stable without preventing the occasional and necessary upheaval (during which we will pause on generating new snapshots)
• It will perhaps increase the number of community members involved in the dev process in trunk/master (some that now focus pretty much all their energies in stable branches)
• It is not expected be a lot of work (we'll need to evaluate ROI after trying for a while)
• Useful snapshots for our upcoming end to end testing process
• Code added to trunk can have more testing before it is backported to a stable branch.

Questions

• Should we go beyond just a tag and test/dogfood automated build system so that releases are fully automatic and a release just becomes deciding which snapshot becomes an official release
  • While more automation is a good thing, I don't think it's wise to use archives (.zip) to distribute this type of software. Folks should be using Git, ideally via Tiki Manager. {}

Related pages

• Daily Build
• Continuous upstream
• Continuous Integration
• How to Have Fewer Bugs in Tiki