releases.rst 2.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051
  1. Release Policy
  2. ##############
  3. What to expect when upgrading Elgg.
  4. In general, we adhere to `semantic versioning`_.
  5. .. _semantic versioning: http://semver.org
  6. Follow the blog to `stay up to date on the latest releases`__.
  7. __ https://community.elgg.org/blog/all
  8. Bugfix Releases (1.9.x)
  9. -----------------------
  10. Every few weeks.
  11. Bugfix releases are made regularly to make sure Elgg stays stable, secure, and bug-free.
  12. The higher the third digit, the more tested and stable the release is.
  13. Since bugfix release focus on fixing bugs and not making major changes,
  14. themes and plugins should work from bugfix release to bugfix release.
  15. Feature Releases (1.x.0)
  16. ------------------------
  17. Every few months.
  18. New features are introduced in Elgg every few months in minor new feature releases.
  19. These versions are identified by the second digit (1.**8**.0).
  20. These releases aren't as mature as bugfix release, but are considered stable and useable.
  21. Though these releases try to be backward compatible,
  22. features are added, unused code removed, and overall improvements are made,
  23. so plugins and themes might need to be updated to make use of the new and improved features.
  24. Major Releases (x.0.0)
  25. ----------------------
  26. Every few years.
  27. Elgg, as all software, inevitably undergoes serious changes and a major new feature release is made.
  28. These releases are opportunities for the core team to make dramatic improvements to the underlying platform.
  29. Themes and plugins from older versions are not expected to work without modification on different major releases.
  30. Release Candidates/Betas
  31. ------------------------
  32. Before feature releases and major releases, the core team will typically offer a release candidate or beta.
  33. These are meant for testing only and should not be considered production quality.
  34. The core team makes these releases available to get some real-world testing and feedback on the release.
  35. That said, the API in release candidates is considered stable, so
  36. once a release candidate is made available, you should feel comfortable writing plugins against any new APIs.