For signing the release, just make sure we add your signing key to the KEYS file. For uploading it, as long as you include the .asc files with the artifacts, you can upload them _anywhere_, and one of the PMC members can download them, verify they're signed correctly, then copy those files to the svn repo for you. Realistically, we only _need_ to commit the release artifact, not the release candidate. Out of convenience, we have a separate dist-dev svn repo where we typically upload release candidates, but for committers, you can upload the RC artifacts wherever.
Footnote: this whole explanation wouldn't apply that well if you also needed access to upload to repository.apache.org for Java artifacts. Since that doesn't seem to be the case, that's one less thing for a PMC member to upload for you after the vote passes. On Thu, 6 Aug 2020 at 04:51, Tobias Frost <t...@debian.org> wrote: > > On Wed, Aug 05, 2020 at 06:08:48PM -0700, Ralph Goers wrote: > > Remember, releases don’t have to be perfect. In practice, you just want > > them to hopefully be better than the prior release. > > this SO-NAME bug can create some havoc down the road, especially at > distributions… So I have some interest in getting that fixed so > here's a patch as basis for discussion: > It makes cmake produces also the same SO-version. (Tested on Linux only, > sorry; > do not own a windows box) > > (Patch also available as PR https://github.com/apache/logging-log4cxx/pull/32) > > Alternatively, log4cxx could change its versioning to match the so name > versioning… > (IOW that would mean it would go to version 11.0.0 with the next release) > That of course means retiring autotools or fixing it… (IMHO retiring would be > ok) > > diff --git a/CMakeLists.txt b/CMakeLists.txt > index 2757cfe7..09254859 100644 > --- a/CMakeLists.txt > +++ b/CMakeLists.txt > @@ -3,6 +3,11 @@ include(src/cmake/projectVersionDetails.cmake) > project(log4cxx VERSION ${log4cxx_VER} LANGUAGES CXX) > include(CTest) > > +# define the SO Version of the library. Version of the log4cxx project is > subtly different than the version of the library > +# (at least in the past it was project vesion: 0.a.b.c and the library so > vesion a.b.c.0 > +set(LIBLOG4CXX_LIB_VERSION > ${log4cxx_VERSION_MINOR}.${log4cxx_VERSION_PATCH}.${log4cxx_VERSION_TWEAK}) > +set(LIBLOG4CXX_LIB_SOVERSION ${log4cxx_VERSION_MINOR}) > + > # FindAPR and FindAPR-util are not provided by APR and APR-Util so source > them locally > list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/src/cmake") > > diff --git a/src/main/cpp/CMakeLists.txt b/src/main/cpp/CMakeLists.txt > index 8f7d6090..213ece5a 100644 > --- a/src/main/cpp/CMakeLists.txt > +++ b/src/main/cpp/CMakeLists.txt > @@ -165,6 +165,6 @@ target_sources(log4cxx > zipcompressaction.cpp > ) > set_target_properties(log4cxx PROPERTIES > - VERSION > ${log4cxx_VERSION_MAJOR}.${log4cxx_VERSION_MINOR}.${log4cxx_VERSION_PATCH} > - SOVERSION ${log4cxx_VERSION_MAJOR} > + VERSION ${LIBLOG4CXX_LIB_VERSION} > + SOVERSION ${LIBLOG4CXX_LIB_SOVERSION} > ) > > Cheers, > -- > tobi > > (For avoidance of doubt, patch is licensed Apache 2.0 as the liblog4cxx > project as well) > > > > Ralph > > > > > On Aug 5, 2020, at 5:00 PM, Robert Middleton <osfan6...@gmail.com> wrote: > > > > > > In the coming week or two I will work on doing an official release for > > > log4cxx. I just need to test on my side that I at least am > > > comfortable with building; I don't expect any issues. > > > > > > The only critical thing at the moment that I can think of is > > > LOG4CXX-512, which I discovered last night. Thorsten, are there any > > > other issues that you can think of that are critical? I'll also close > > > all of the issues that I put in my last email on feature proposals at > > > that time, unless you object to those. > > > > > > -Robert Middleton > > > > > > > -- Matt Sicker <boa...@gmail.com>
