Files
eden/docs/ReleasePolicy.md
lizzie 1e06c6f752 [docs] troubleshoot section, release policies, gpu documentation (#3078)
- gpu docs
- user guide stuff
- removed unused named.svg
- added link to ES-DE frontend stuff from 3rdparty
 Signed-off-by: lizzie lizzie@eden-emu.dev

Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3078
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
2025-12-12 18:36:19 +01:00

1.6 KiB

Release Policy

While releases are usually made at the discretion of the team, we feel that establishing a clearer guideline on how those come to be will help expectations when it comes to features and fixes per version.

Release candidates

Every full release is preceded by at least, 3 release candidates. The reasoning is that each week of the month, there will be a release candidate, with the "4th one" being the final full release.

The main expectation is that the release candidates bring both fixes and, sometimes, new features. But not guarantee a regression-free experience.

The criteria for choosing a date for a release candidate is at discretion, or "perceived necesity" at any given time.

Full release

A full release means there are no major leftover regressions, importantly this means that a grand portion of regressions found between release candidates are swept out before declaring a full release. This doesn't mean a full release is regression-free; but we do a best-effort approach to reduce them for end-users.

The main expectation is that users can safely upgrade from a stable build to another, with no major regressions.

Snapshot/rolling release

While we don't publish rolling releases, we are aware users may compile from source and/or provide binaries to master builds of the project.

This is mostly fine since we keep master very stable from major hiccups. However sometimes bugs do slip between tests or reviews - so users are advised to keep that in mind.

We advise that users also read git logs (git log --oneline) before recompiling to get a clearer picture of the changes given into the emulator.