From this point onwards v3.0.x no major new features will be accepted into v3.0.x. A new branch, v3.1.x, has been forked from master. All new feature development should be done on the v3.1.x branch. All new pull requests for features should be submitted against v3.1.x. Major re-architecturing will then start in master. v3.1.x will be used for development/preview releases. We'll add tags regularly but versions will not be released on the freeRADIUS website. Changes in v3.1.x will be merged to master. Bug fixes in v3.0.x will be merged into v3.1.x and master where relevant. The primary reasons for creating a new branch are: - We need to stabilise v3.0.x, but still need to add new features to the server. - Maintaining compatibility with v3.0.x is getting difficult. The new/old escapes code is particularly annoying to unpick. In v3.1.x all the code that allowed for the old escaping mode will be removed, as will support for the old client syntax, and all the config items currently marked as deprecated in v3.0.x. - There's code in the current master than should have been merged into v3.0.x a while back, but hasn't. The code concerns error handling in update sections and conditions. Restoring atomic behaviour for the update sections, and having xlats trigger abort and rollback behaviour on errors is the behaviour we should aim for. However, if we reintroduced atomic update sections in v3.0.x it might break lots of existing configs. Master will not be config compatible. Unlang, and the majority of the module syntax will be. So it won't be as painful as migrating from v2 to v3, but the authorize, authenticate, post-auth sections won't exist in their current form. We need a syntax that can describe processing flows for multiple protocols, not just RADIUS. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (1)
-
Arran Cudbard-Bell