|Deletions are marked like this.||Additions are marked like this.|
|Line 10:||Line 10:|
| 1. #52653: load_responses has side effect to set dest(__<var>) on multiple occurences of var
1. #53396: Tests don't run on Solaris (id command has different output format)
|Line 14:||Line 17:|
| * #52653: load_responses has side effect to set dest(__<var>) on multiple occurences of var
* #53396: Tests don't run on Solaris (id command has different output format)
I take for granted that next release of Rivet will be numbered 2.1.0. This is to mark the dropping of tcl 8.4 support and the introduction of new features or modification that could break existing applications.
DONE in svn 'trunk'
Configuration defaults moved from C code into configure.ac. Documentation now reflects this fact (status: done and committed in trunk)
New configuration directive ServerInitScript creates an interpreter after the configuration has been parsed and its internal representation built, but before children are forked.(status: done)
Rivet commands put into ::Rivet namespace. Commands are by default put on the namespace export list, so that existing applications should work just by adding a 'namespace import ::Rivet::*' in a initialization script. This behavior can changed when building Rivet passing to 'configure' the switch --disable-import-rivet-command and --disable-rivet-command-export (status: done)
Dropping Apache 1.x support.(status: done)
#52653: load_responses has side effect to set dest(<var>) on multiple occurences of var
- #53396: Tests don't run on Solaris (id command has different output format)
Commands in rivetCrypt.c and rivetList.c: what to do with them? Still to be documented (status: to do)
- #53463: package Rivet should provide actual version number
- #53732: Functions to get public variables do not return anything...
- #53733: DIOObject count command fails when -keyfield is not specified
- The shorthand construct for string simple output should have a manual page on its own
many of thes bugfixes should target also the code in branches/2.0 for a new 2.0.6 release
Multipart message parsing should be rewritten to rely completely on libapreq. (status: to do)
#53805: ?> should only be interpreted as ENDTAG after a command terminator
- #53661: Content-Type for POST requests are unreasonably restrictive and hardcoded