| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate- devel
---------- Forwarded message ----------
From: Gregor Jasny <gjasny@xxxxxxxxxxxxxx>
To: resiprocate-devel@xxxxxxxxxxxxxxx
Cc:
Bcc:
Date: Tue, 6 Mar 2018 21:24:56 +0100
Subject: Questions about resiprocate roadmap
Hello,
I'd like to share some thoughts and ask some questions about the future
roadmap of resiprocate.
* Schedule for stable 1.11 release *
It's been a long time since the last resiprocate stable release. The
first 1.11 alpha was tagged in November 2016, the first beta in January
2017. Debian seems to have picked up those betas and ships them in the
stable distribution release.
Since the last beta a lot of bug fixes went into master. Also
resiprocate is now compatible with OpenSSL 1.1 which is crucial for most
Linux distributions because they try to phase out OpenSSL 1.0
Do you see any blockers preventing a 1.11 release or do you have patches
that should definitely be part of an upcoming stable release? What's the
release process for a new stable resiprocate?
* Switch to C++11 *
At $Company we use resiprocate in a C++11 (and soon C++14 code base).
Resiprocate's use of auto_ptr also on external interfaces gives us some
deprecation warnings for auto_ptr. Surerely we could silence those, but
AFAIR the final C++17 standard removed auto_ptr completely. So users of
resiprocate will have to enable special C++ standard library
compatibility flags, soon.
What do you think about moving to C++11 after the 1.11 release has been
branched off?
* Google Test as a test driver *
In several projects I used Google Test (and Mock) as a testing
framework. If you don't abuse it it results in elegant and nicely
readable tests. Also any detected errors are pretty descriptive and help
the developer to figure out what's going on.
Google Test supports fusing all own internal source files into one
single file so embedding into a project isn't too intrusive. I prepared
a test branch with a single converted test here:
https://github.com/gjasny/resiprocate/tree/add-google- mock
Google Test supports grouping of test cases into test suites and
theoretically we could create a single unit test binary per library.
* clang-format rules file *
Regardless of how hard I try, there are always some formatting errors in
my pull requests. How about creating a clang-format file with the
preferred formatting and add it to the repo? One could the use 'git
clang-format' (or standalone clang-format) to format any patches to the
desired style.
* CMake buildsystem
My workstation OS is right now MacOS so there is no up-to-date
buildsystem with IDE support within the resiprocate repository. In the
past there was an initiative by Francis Joanis and Byron Campen to add
the CMake buildsystem. I picked up their work and adjusted it to the
current code base. You can find a proof-of-concept that builds rutil,
resip, dum, reflow, and reTurn here:
https://github.com/resiprocate/resiprocate/pull/ 107
It works with CLion, Xcode and Ninja/Make on MacOS and Ubuntu 16.04.
I'll test (and probably fix) it on Windows later. My general question
would be if there is interest in CMake at all and if you could imagine
to remove the Visual Studio solutions and projects in favour of CMake to
reduce maintenance cost. (Same question for autotools).
Thank you for your feedback!
Cheers,
Gregor