Difference between revisions of "Release policy"
Jump to navigation
Jump to search
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
[[Politique de version|En français]] |
|||
When the stuff is ready? |
When the stuff is ready? |
||
Some things that should always be checked: |
Some things that should always be checked: |
||
* [[Testvoc]] should be clean |
|||
* whether it compiles and runs with the latest _release_ of apertium/lttoolbox (and other required packages) |
|||
* |
* Whether it compiles and runs with the latest _release_ of apertium/lttoolbox (and other required packages) |
||
* Whether it compiles and installs correctly as a tarball created with make dist (see [[Making_a_release#Testing]]) |
|||
* |
* If there are regression tests, check that these pass |
||
* |
* Run a corpus through it, and ensure there are no debug symbols (#, @) |
||
* |
* Some transfer bugs can be rooted out by compiling the transfer files with either [https://github.com/ggm/vm-for-transfer-cpp vm-for-transfer-cpp] or <code>apertium-preprocess-transfer-bytecode-j</code> from [[Lttoolbox-java]] |
||
==See also== |
==See also== |
Latest revision as of 12:07, 18 September 2015
When the stuff is ready?
Some things that should always be checked:
- Testvoc should be clean
- Whether it compiles and runs with the latest _release_ of apertium/lttoolbox (and other required packages)
- Whether it compiles and installs correctly as a tarball created with make dist (see Making_a_release#Testing)
- If there are regression tests, check that these pass
- Run a corpus through it, and ensure there are no debug symbols (#, @)
- Some transfer bugs can be rooted out by compiling the transfer files with either vm-for-transfer-cpp or
apertium-preprocess-transfer-bytecode-j
from Lttoolbox-java