Could a new official version be released?
The last release is from 2021 - version 3.0.1.
Could we have another release please? We are using package management system and using a git hash id from the master branch is possible, but it will be much easier to track versions if we have another public release.
P.S. Be sure to also update CMakeLists.txt with the latest version tag if a new release is issued.
I especially think that the fix for #826 merits a new release. People who build with the latest compilers are currently unable to use a released version of this library.
Yes please release a new version! If the library has been changed to "live at head" versioning, please let us know so I can update vcpkg to the new scheme.
I highly recommend "live at head". "head" is always kept in a shippable state.
That being said, I will try to get one last release out in the next week.
Bark bark :)
I would really like to skip 50 patches from kodi source tree just because the version is not tagged :(
I hear you. Giving the parsing fixes some time to gel. And trying to find time to review the most critical PR's first. And I'm technically unable to review those PR's which involve make files.
Or I could just tag master as is...
I can help you with make and cmake if needed. Just tag me on PRs you need help with!
I'll take it. Any PR tagged with CMake is yours.
I managed to complete xbmc/xbmc#18727 and getting back here as promised last week:
- https://github.com/HowardHinnant/date/pull/829 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/816 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/814 - :question: unreproducible on my side, asked author if he still needs it
- https://github.com/HowardHinnant/date/pull/808 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/807 - :question: needs your opinion
- https://github.com/HowardHinnant/date/pull/806 - :question: needs your opinion
- https://github.com/HowardHinnant/date/pull/804 - :question: needs your opinion
- https://github.com/HowardHinnant/date/pull/795 - :question: works but needs fix for CMake < 3.15
- https://github.com/HowardHinnant/date/pull/787 - :ok: LGTM (see comment)
- https://github.com/HowardHinnant/date/pull/769 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/766 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/755 - :question: (see comment)
- https://github.com/HowardHinnant/date/pull/753 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/752 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/744 - :ok: LGTM
- https://github.com/HowardHinnant/date/pull/611 - :no_entry: IMHO not needed (see commemt)
Other patches are stale for many years :)
And I would like to add my patch that allows using Android's compiled tzdata. This should be safe as modern Android versions ship updatable tzdata in APEX (Android Pone EXpress) format via Google Play.
The only concern regards this patch is that it adds new public method void time_zone::parse_from_android_tzdata(std::ifstream& inf, const std::size_t off) that in fact must be private as it is used only by date::init_tzdb and is not supposed for external consumption. I guess it can be solved by fiddling with friend classes but I hope someone more knowledgeable in C++ suggests an elegant solution.
Thanks for new 3.0.2 tag @HowardHinnant ! This issue can be closed I think :)
@Tachi107 Please upload new version to Debian :)
@Tachi107 Makes sense to add #851 as a Debian patch for now, too!