Hello,
during past on-site/online devel meetings as well as on mailing lists or tracker, there were various discussions around the idea or requests to make new features available quicker to stable branches.
Of course, one can do local git cherry-picking, but I thought to bring this in discussion and see if makes sense to get something more coordinated between developers and community. Therefore I am cross-posting to sr-dev and sr-users to see if there is interest for it from both communities.
Somehow inspired from Debian, my first idea would be to create a "x.y-backports" branch, where "x.y" is the branch for the stable release series. For example, with 5.6 release series built from branch "5.6", there could be "5.6-backports" branch which is kept in sync in "5.6" but also can get "selected" new features from devel (master branch) backported.
The "selected" new features should be mostly a matter of the people willing to put effort in backporting, but I would consider a list recommendations not to end up with devel and backports branches being more or less the same. For example, in the "no-backporting" list:
- no backporting of completely new modules - no backporting of significant changes to the config file language and native scripting interpreter
In the "ok-to-backport":
- updates to enable use with newer versions of external libraries - changes to make some functions/modules to cope better with the core infrastructure or end points
Commits to the backports branch can be proposed via pull requests.
The backports branch should be done only for latest stable version, picking from the development version. Right now it would be 5.6, but we can wait till 5.7 is released and then have it for it.
No packaging and no official releases should be made from backports branch, only a git branch to be maintained as a community effort. Of course, if someone wants to put more resources into it, we can discuss about.
Anyhow, the first questions would be if such branch sounds good to have and if there are people that think they can also contribute to maintain it.
Cheers, Daniel
On 2 May 2023, at 12:10, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
during past on-site/online devel meetings as well as on mailing lists or tracker, there were various discussions around the idea or requests to make new features available quicker to stable branches.
Of course, one can do local git cherry-picking, but I thought to bring this in discussion and see if makes sense to get something more coordinated between developers and community. Therefore I am cross-posting to sr-dev and sr-users to see if there is interest for it from both communities.
Somehow inspired from Debian, my first idea would be to create a "x.y-backports" branch, where "x.y" is the branch for the stable release series. For example, with 5.6 release series built from branch "5.6", there could be "5.6-backports" branch which is kept in sync in "5.6" but also can get "selected" new features from devel (master branch) backported.
The "selected" new features should be mostly a matter of the people willing to put effort in backporting, but I would consider a list recommendations not to end up with devel and backports branches being more or less the same. For example, in the "no-backporting" list:
- no backporting of completely new modules
- no backporting of significant changes to the config file language
and native scripting interpreter
I would add - no changes to database schemas or versions
/O
In the "ok-to-backport":
- updates to enable use with newer versions of external libraries
- changes to make some functions/modules to cope better with the core
infrastructure or end points
Commits to the backports branch can be proposed via pull requests.
The backports branch should be done only for latest stable version, picking from the development version. Right now it would be 5.6, but we can wait till 5.7 is released and then have it for it.
No packaging and no official releases should be made from backports branch, only a git branch to be maintained as a community effort. Of course, if someone wants to put more resources into it, we can discuss about.
Anyhow, the first questions would be if such branch sounds good to have and if there are people that think they can also contribute to maintain it.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-leave@lists.kamailio.org
Hello,
On 2/5/23 12:10, Daniel-Constantin Mierla wrote: [...]
Somehow inspired from Debian, my first idea would be to create a "x.y-backports" branch, where "x.y" is the branch for the stable release series. For example, with 5.6 release series built from branch "5.6", there could be "5.6-backports" branch which is kept in sync in "5.6" but also can get "selected" new features from devel (master branch) backported.
The "selected" new features should be mostly a matter of the people willing to put effort in backporting, but I would consider a list recommendations not to end up with devel and backports branches being more or less the same. For example, in the "no-backporting" list:
- no backporting of completely new modules - no backporting of significant changes to the config file language and native scripting interpreter
In the "ok-to-backport":
- updates to enable use with newer versions of external libraries - changes to make some functions/modules to cope better with the core infrastructure or end points
Commits to the backports branch can be proposed via pull requests.
The backports branch should be done only for latest stable version, picking from the development version. Right now it would be 5.6, but we can wait till 5.7 is released and then have it for it.
No packaging and no official releases should be made from backports branch, only a git branch to be maintained as a community effort. Of course, if someone wants to put more resources into it, we can discuss about.
I've no problem to provide the debs without formal releases. It could be handle as we already do for X.Y branches. A nightly build if changes are detected.
Anyhow, the first questions would be if such branch sounds good to have and if there are people that think they can also contribute to maintain it.
It sounds fine to me
-
Daniel-Constantin Mierla -
Olle E. Johansson -
Victor Seva