1e06c6f752
- 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>
26 lines
1.6 KiB
Markdown
26 lines
1.6 KiB
Markdown
# 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.
|