|
Here you can find a summary of the changes in the library that could require an effort from its users, like the ones affecting the API, ABI or semantics. You should always clean all your files before upgrading. While I don't expect the transaction on-disk format to change, it's a good practise and it doesn't take much effort. When it's mandatory, it will be noted. -> 0.50 (Big API change) - Structures are now opaque types: struct jfs -> jfs_t; jopen() returns a pointer to one, jclose() frees it. struct jtrans -> jtrans_t; jtrans_new() returns a pointer to one, jtrans_free() frees it. - Renamed jtrans_init() to jtrans_new(). - jtrans_commit() returns -1 on recovered errors, -2 on unrecovered errors (which are an indication of a severe underlying condition). - jtrans_add() returns 0 on success and -1 on errors (it used to return 1 on success and 0 on errors). - jfsck() now has an additional "flags" parameter, which should be set to 0 to select the default behaviour. - jfsck_cleanup() was removed, and now jfsck() cleans up by default. -> 0.25 - It is no longer necessary to pass O_SYNC to jopen() if lingering transactions are not in use. - libjio.h can no longer be included from C++ source without surrounding it by an 'extern "C"'. This obviously should only affect C++ applications. -> 0.24 - The return values of jfsck() have changed, so applications using it need to be recompiled. - Python bindings' jfsck(), jfsck_cleanup(), jsync(), jwrite() and jpwrite() now raise an IOError on failures. -> 0.22 - Applications need to be recompiled due to a change in the jfs structure. -> 0.20 - Applications need to be recompiled due to a change in the jfs structure. - When you link your applications with libjio, you need to make sure you compile using large file support. -> 0.19 - Applications need to be recompiled due to a change in the flag numbering. - A flag number has changed, from J_COMMITED to J_COMMITTED. If you used that flag, you need to rename it. |