summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorStefano Lattarini <stefano.lattarini@gmail.com>2013-05-22 20:13:41 +0200
committerStefano Lattarini <stefano.lattarini@gmail.com>2013-05-22 20:13:41 +0200
commitd9a3a4477bdc346f515786cf70568db25a167422 (patch)
tree6816e4cab64dbae095cecbf6a5672883136b91fd /HACKING
parent15996acc36367acf3a653eea6e1fbec03b00a964 (diff)
downloadautomake-d9a3a4477bdc346f515786cf70568db25a167422.tar.gz
HACKING: it's OK to do testsuite refactoring in a micro version
Reported-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING5
1 files changed, 4 insertions, 1 deletions
diff --git a/HACKING b/HACKING
index 3ce2e66df..194a77530 100644
--- a/HACKING
+++ b/HACKING
@@ -111,7 +111,10 @@
* Micro releases should be just bug-fixing releases; no new features
should be added, and ideally, only trivial bugs, recent regressions,
- or documentation issues should be addressed by them.
+ or documentation issues should be addressed by them. On the other
+ hand, it's OK to include testsuite work and even testsuite refactoring
+ in a micro version, since a regression there is not going to annoy or
+ inconvenience Automake users, but only the Automake developers.
* Minor releases can introduce new "safe" features, do non-trivial but
mostly safe code clean-ups, and even add new runtime warnings (rigorously