> On 2 May 2023, at 12:10, Daniel-Constantin Mierla <[email protected]> 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 [email protected]

_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to [email protected]

Reply via email to