mirror of
https://github.com/radareorg/radare2.git
synced 2024-12-12 23:46:36 +00:00
cdd80105cb
- Managing breakpoints for the core
- Initial work on the support for breakpoints
for the r_debug plugins
* Adding some dummy work for context support in r_anal
* Make asm_set_bits check per-plugin supported bit sizes
- Now asm plugins have 'arch' and 'bits' attributes
- Used to setup default callbacks for undefined 'assemble' callback
- Also used to avoid setting asm.bits eval variable to invalid values
- We need a way to display all this data
* Added DEFAULT_ARCH in config.h to setup default arch to asm and anal
* Added r_config_set_i_cb()
- Make r_config_set restore value when callback is called and fails
- asm.bits now has a config callback
* Added _LAST in some r_anal enums
55 lines
2.0 KiB
Plaintext
55 lines
2.0 KiB
Plaintext
radare2 releasing rules
|
|
=======================
|
|
|
|
The objective of this paper is to determine a set of rules to be done before
|
|
each release and define the instructions for generating the distribution
|
|
tarball together with a scheduler.
|
|
|
|
* We try to release every 1/2 months
|
|
* Version numbering (actually we dont follow any rules for this)
|
|
* Codenames for releases MUST be funny (until we didnt get a name that can make
|
|
me laught, we should not release anything!)
|
|
|
|
Before any release we have to:
|
|
|
|
- Remove warnings
|
|
|
|
We dont want to fall in the warning nightmare of r1. Releases should contain
|
|
no warnings with gcc -Wall or at least no dangerous ones.
|
|
|
|
- Sync Vala APIs
|
|
|
|
Keeping the VAPI files the last ones to be developed between release cycles
|
|
we ensure that we do not have to maintain synced the code with the vapis
|
|
and it is possible to easily draw the LIBR API evolution by just diffing
|
|
the vapi directory.
|
|
|
|
- Unit test programs
|
|
|
|
If available, it would be good to have some unit tests to check nothing is
|
|
broken. Maybe Vala is the way to go when writing tests, because this way
|
|
we ensure that pkg-config, libr and vapis works in a shot.
|
|
|
|
- Test build on different platforms
|
|
|
|
The same codebase should be compilable on *nix and w32 systems without
|
|
modifications. It should be also possible to build it with make threads,
|
|
so using quadcore boxes with -j8 should be a good place for finding
|
|
race conditions in the build system.
|
|
|
|
- Remove commented code and review TODO/BUG/XXX comments
|
|
|
|
While developing a new release, it's pretty common to keep old versions of
|
|
the code for testing parts of libraries and be able to go back or find bugs
|
|
while refactoring code or re-doing-it from scratch. This code, should be
|
|
reviewed and removed if necessary.
|
|
|
|
$ grep -r -e TODO -e XXX -e FIX libr
|
|
|
|
- Graph per symbol-module dependency graph to identify unused/dupped/-
|
|
simplificable use cases of the API for every module.
|
|
|
|
FUTURE
|
|
|
|
- Commands should be handled in a structural way, not by a bunch of switch/cases
|