Release Process

1. Stages

• alpha1
  • Alpha is for preview purposes only.
  • it is intended to be a technology preview aimed at early adopters, testers, translators
  • Do not use alpha releases on production systems!
• alpha2
• beta1
  • Beta releases are appropriate for use with new development. Within beta releases, the features and compatibility should remain consistent. However beta releases may contain numerous and major unaddressed bugs.
• beta2
  • is available for testers, extension developers, and other people who are curious to follow the development of the next release
• rc1
  • Release Candidates are believed stable, having passed all internal testing, and with all known fatal runtime bugs fixed. However this release has not been in widespread use long enough to know for sure that all bugs have been identified.
    • wait to declare something RC until code stabilizes and critical bugs are fixed
  • feature freeze -> testing and debugging ->
    • This release is ready for widespread testing, and we’re encouraging everyone to download and test the beta releases. Please run the release through your usual routine, and let us know about any bugs or other issues that you find. Remember that this is a beta release, and is not suitable for use on production systems.
  • For translators, this is the first call to update the translations to the current set of strings, which should not change much until final.
• rc2
• final
  • also know as Production releases, are stable, having successfully passed through all earlier release stages and believed to be reliable, free of serious bugs, and suitable for use in production systems
  • All users are advised to upgrade.
• m1
  • Maintenance release

2. Issue tracker

• update issues in bugtracker
• set release date

3. Change Log

4. Release Notes

• Upgrade from previous versions
  • Component compatibility
  • Configuration
• Highlights
• Call for Localization
  • If you can help with languages other than English and German, it would be appreciated.
• Testing
  • Most Annoying Bugs
    • While many bugs have been eliminated since the last beta, we still have a few remaining (and new) bugs that testers should be aware of:
• Themes
• Hacks / Patches

5. Build packages

• tarball
• zip
• name the folder within the package according the release
  • wacko.r6.0.38
  • wacko.r6.2.1
  • wacko.r7.0.1

const PHP_ERROR_REPORTING			= 0;		

'sql_mode' => '0',		

1. On your local machine (or CI), run:

   composer install --no-dev --optimize-autoloader		

   
   
2. Create a clean distribution archive that includes everything users need.
3. Upload the resulting .zip / .tar.gz as an asset to a new GitHub Release.

5.1. Create the Distribution Package

6. Repository

• tag the release
• branch final release

7. Update Files

• Latest development version
• Latest released testing version
• Latest released stable version

7.1. Update file references

wackowiki-6.2.1.zip^[link5] (2.9 MiB)

Development version
(see Repository^[link6])

Beta version
wackowiki-6.3.0-beta8.zip

8. Release notices and announcements

• SF.net file release system's e-mail notices
• Announcement -mailing list
• SF.net Project news
• Draft the new release on GitHub
  • https://github.com/WackoWiki/wackowiki/releases
  • https://codeberg.org/WackoWiki/wackowiki/releases
• Web pages
  • https://freshcode.club/projects/wackowiki
• Feed
  • https://github.com/WackoWiki/wackowiki/releases.atom
  • https://codeberg.org/WackoWiki/wackowiki/releases.rss