RFC: selective backports to latest stable as a dedicated git branch
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 -- 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
> 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 -- ----------------------------------------------------------------- | ,''`. Victor Seva | | : :' : linuxmaniac@torreviejawireless.org | | `. `' PGP Key ID: 0x51A09B18CF5A5068 | | `- Debian Developer | -----------------------------------------------------------------
participants (3)
-
Daniel-Constantin Mierla -
Olle E. Johansson -
Victor Seva