> On 2 May 2023, at 12:10, Daniel-Constantin Mierla 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-le...@lists.kamailio.org
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
