You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Robert Middleton <os...@gmail.com> on 2020/08/09 17:24:41 UTC
[VOTE] [log4xx] Release log4cxx 0.11.0
I've run through the release of log4cxx 0.11.0. There's still something
strange about how it all works(mostly due to the tooling of shell
script/maven/ant/cmake/autotools). However, I do believe that I have a
workable release at this point. A quick note on the release: I did the
'mvn release:prepare' manually, which is where these artifacts come from;
running through the 'mvn release:perform' causes the generated files to be
-SNAPSHOT versioned, instead of 0.11.0. This means that the version of the
pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't really
used to build I don't think this will be an issue.
Artifacts uploaded here:
https://dist.apache.org/repos/dist/dev/logging/log4cxx/
tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
The artifacts are signed, although I still need to send my key to Matt so
he can import it into the logging KEYS file.
-Robert Middleton
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
Apache announcements sent to the announcement list have a few requirements. They should include a link to the web site and must include a link to the download page near the front of the email. As Matt said, they must look like they come from your apache.org <http://apache.org/> email address. I have mine aliased to the address I use here and set up my email client to be able to use the apache.org <http://apache.org/> email when I am emailing the mailing list. However, because I am not subscribed to this list using the apache.org <http://apache.org/> account I have to send 2 announcement emails.
You can also create an announcement in the ASF Blog that will appear for a short amount of time in the “Latest News” section on the ASF home page.
Ralph
> On Aug 24, 2020, at 10:46 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Make sure to move the tag into a rel/ namespaced tag. Those are immutable.
> For announcing, make sure to send from your Apache email and CC
> announce@apache.org.
>
> On Mon, Aug 24, 2020 at 12:35 Robert Middleton <os...@gmail.com> wrote:
>
>> Since we have an actual release now, should we make an announcement email
>>
>> on the general@logging.apache.org list? I can write up a blurb, but I'm
>>
>> not sure who can post to that list.
>>
>>
>>
>> I've also updated the tag for the release appropriately(v0.11.0)
>>
>>
>>
>> -Robert Middleton
>>
>>
>>
>> On Sun, Aug 23, 2020 at 1:09 PM Matt Sicker <bo...@gmail.com> wrote:
>>
>>
>>
>>> The Log4j release-2.x branch is only there because master is
>>
>>> effectively the "release-3.x" branch right now. We forked the branch
>>
>>> to continue 2.x releases while we started making breaking changes in
>>
>>> the 3.x branch (mostly involving moving plugins around; the API is
>>
>>> still the same).
>>
>>>
>>
>>> On Sun, 23 Aug 2020 at 06:41, Thorsten Schöning <ts...@am-soft.de>
>>
>>> wrote:
>>
>>>>
>>
>>>> Guten Tag Ralph Goers,
>>
>>>> am Samstag, 22. August 2020 um 19:04 schrieben Sie:
>>
>>>>
>>
>>>>> I didn’t try to run the build from master. I checked out the
>>
>>>>> release tag.
>>
>>>>
>>
>>>> The site needed to be updated without new releases in the past
>>
>>>> already. I didn't see how this was possible without a branch, so
>>
>>>> simply created one and thought it was a good idea to have one for new
>>
>>>> releases as well. From what I seen, Log4j has a release-2.x branch as
>>
>>>> well. So it might perfectly be that I didn't even consider generating
>>
>>>> the site based on a release tag at all.
>>
>>>>
>>
>>>>> [...]I expected
>>
>>>>> to see the log4cxx release version in the pom on the release tag and
>>
>>>>> it wasn’t there.
>>
>>>>
>>
>>>> This heavily depends on how exactly Robert created the release and
>>
>>>> simply needs to be debugged further. The created scripts should have
>>
>>>> taken care of version numbers, but might not work properly under all
>>
>>>> conditions or whatever. The goal was that "release_prepare" should
>>
>>>> have created a branch and associated tags with correct numbers to base
>>
>>>> releases on. In the end, "changes.xml" wasn't properly updates as well
>>
>>>> for some reason.
>>
>>>>
>>
>>>> So either this needs to be debugged or, as has been discussed already,
>>
>>>> one needs to implement new release-handling without using MVN at all.
>>
>>>> Though I think fixing the existing problems and/or improve docs is the
>>
>>>> easier way forward right now.
>>
>>>>
>>
>>>>> Once a release tag is created no modifications can
>>
>>>>> be made so everything needs to be correct. In Log4j I only create a
>>
>>>>> release branch from the tag if a patch to that release is required.
>>
>>>>> To date, we have never done that.
>>
>>>>
>>
>>>> When I worked last on a release years ago, things were expected to get
>>
>>>> changed or simply didn't work for some reason and that's only easily
>>
>>>> possible with a release branch in my opinion. Manually creating
>>
>>>> branches on each and every RC didn't seem like a good way to me.
>>
>>>>
>>
>>>> Mit freundlichen Grüßen,
>>
>>>>
>>
>>>> Thorsten Schöning
>>
>>>>
>>
>>>> --
>>
>>>> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
>>
>>>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>>
>>>>
>>
>>>> Telefon...........05151- 9468- 55
>>
>>>> Fax...............05151- 9468- 88
>>
>>>> Mobil..............0178-8 9468- 04
>>
>>>>
>>
>>>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>>
>>>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>>
>>>>
>>
>>>
>>
>>>
>>
>>> --
>>
>>> Matt Sicker <bo...@gmail.com>
>>
>>>
>>
>> --
> Matt Sicker <bo...@gmail.com>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Matt Sicker <bo...@gmail.com>.
Make sure to move the tag into a rel/ namespaced tag. Those are immutable.
For announcing, make sure to send from your Apache email and CC
announce@apache.org.
On Mon, Aug 24, 2020 at 12:35 Robert Middleton <os...@gmail.com> wrote:
> Since we have an actual release now, should we make an announcement email
>
> on the general@logging.apache.org list? I can write up a blurb, but I'm
>
> not sure who can post to that list.
>
>
>
> I've also updated the tag for the release appropriately(v0.11.0)
>
>
>
> -Robert Middleton
>
>
>
> On Sun, Aug 23, 2020 at 1:09 PM Matt Sicker <bo...@gmail.com> wrote:
>
>
>
> > The Log4j release-2.x branch is only there because master is
>
> > effectively the "release-3.x" branch right now. We forked the branch
>
> > to continue 2.x releases while we started making breaking changes in
>
> > the 3.x branch (mostly involving moving plugins around; the API is
>
> > still the same).
>
> >
>
> > On Sun, 23 Aug 2020 at 06:41, Thorsten Schöning <ts...@am-soft.de>
>
> > wrote:
>
> > >
>
> > > Guten Tag Ralph Goers,
>
> > > am Samstag, 22. August 2020 um 19:04 schrieben Sie:
>
> > >
>
> > > > I didn’t try to run the build from master. I checked out the
>
> > > > release tag.
>
> > >
>
> > > The site needed to be updated without new releases in the past
>
> > > already. I didn't see how this was possible without a branch, so
>
> > > simply created one and thought it was a good idea to have one for new
>
> > > releases as well. From what I seen, Log4j has a release-2.x branch as
>
> > > well. So it might perfectly be that I didn't even consider generating
>
> > > the site based on a release tag at all.
>
> > >
>
> > > > [...]I expected
>
> > > > to see the log4cxx release version in the pom on the release tag and
>
> > > > it wasn’t there.
>
> > >
>
> > > This heavily depends on how exactly Robert created the release and
>
> > > simply needs to be debugged further. The created scripts should have
>
> > > taken care of version numbers, but might not work properly under all
>
> > > conditions or whatever. The goal was that "release_prepare" should
>
> > > have created a branch and associated tags with correct numbers to base
>
> > > releases on. In the end, "changes.xml" wasn't properly updates as well
>
> > > for some reason.
>
> > >
>
> > > So either this needs to be debugged or, as has been discussed already,
>
> > > one needs to implement new release-handling without using MVN at all.
>
> > > Though I think fixing the existing problems and/or improve docs is the
>
> > > easier way forward right now.
>
> > >
>
> > > > Once a release tag is created no modifications can
>
> > > > be made so everything needs to be correct. In Log4j I only create a
>
> > > > release branch from the tag if a patch to that release is required.
>
> > > > To date, we have never done that.
>
> > >
>
> > > When I worked last on a release years ago, things were expected to get
>
> > > changed or simply didn't work for some reason and that's only easily
>
> > > possible with a release branch in my opinion. Manually creating
>
> > > branches on each and every RC didn't seem like a good way to me.
>
> > >
>
> > > Mit freundlichen Grüßen,
>
> > >
>
> > > Thorsten Schöning
>
> > >
>
> > > --
>
> > > Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
>
> > > AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> > >
>
> > > Telefon...........05151- 9468- 55
>
> > > Fax...............05151- 9468- 88
>
> > > Mobil..............0178-8 9468- 04
>
> > >
>
> > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>
> > > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
> > >
>
> >
>
> >
>
> > --
>
> > Matt Sicker <bo...@gmail.com>
>
> >
>
> --
Matt Sicker <bo...@gmail.com>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Robert Middleton <os...@gmail.com>.
Since we have an actual release now, should we make an announcement email
on the general@logging.apache.org list? I can write up a blurb, but I'm
not sure who can post to that list.
I've also updated the tag for the release appropriately(v0.11.0)
-Robert Middleton
On Sun, Aug 23, 2020 at 1:09 PM Matt Sicker <bo...@gmail.com> wrote:
> The Log4j release-2.x branch is only there because master is
> effectively the "release-3.x" branch right now. We forked the branch
> to continue 2.x releases while we started making breaking changes in
> the 3.x branch (mostly involving moving plugins around; the API is
> still the same).
>
> On Sun, 23 Aug 2020 at 06:41, Thorsten Schöning <ts...@am-soft.de>
> wrote:
> >
> > Guten Tag Ralph Goers,
> > am Samstag, 22. August 2020 um 19:04 schrieben Sie:
> >
> > > I didn’t try to run the build from master. I checked out the
> > > release tag.
> >
> > The site needed to be updated without new releases in the past
> > already. I didn't see how this was possible without a branch, so
> > simply created one and thought it was a good idea to have one for new
> > releases as well. From what I seen, Log4j has a release-2.x branch as
> > well. So it might perfectly be that I didn't even consider generating
> > the site based on a release tag at all.
> >
> > > [...]I expected
> > > to see the log4cxx release version in the pom on the release tag and
> > > it wasn’t there.
> >
> > This heavily depends on how exactly Robert created the release and
> > simply needs to be debugged further. The created scripts should have
> > taken care of version numbers, but might not work properly under all
> > conditions or whatever. The goal was that "release_prepare" should
> > have created a branch and associated tags with correct numbers to base
> > releases on. In the end, "changes.xml" wasn't properly updates as well
> > for some reason.
> >
> > So either this needs to be debugged or, as has been discussed already,
> > one needs to implement new release-handling without using MVN at all.
> > Though I think fixing the existing problems and/or improve docs is the
> > easier way forward right now.
> >
> > > Once a release tag is created no modifications can
> > > be made so everything needs to be correct. In Log4j I only create a
> > > release branch from the tag if a patch to that release is required.
> > > To date, we have never done that.
> >
> > When I worked last on a release years ago, things were expected to get
> > changed or simply didn't work for some reason and that's only easily
> > possible with a release branch in my opinion. Manually creating
> > branches on each and every RC didn't seem like a good way to me.
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
> > --
> > Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> > AM-SoFT IT-Systeme http://www.AM-SoFT.de/
> >
> > Telefon...........05151- 9468- 55
> > Fax...............05151- 9468- 88
> > Mobil..............0178-8 9468- 04
> >
> > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Matt Sicker <bo...@gmail.com>.
The Log4j release-2.x branch is only there because master is
effectively the "release-3.x" branch right now. We forked the branch
to continue 2.x releases while we started making breaking changes in
the 3.x branch (mostly involving moving plugins around; the API is
still the same).
On Sun, 23 Aug 2020 at 06:41, Thorsten Schöning <ts...@am-soft.de> wrote:
>
> Guten Tag Ralph Goers,
> am Samstag, 22. August 2020 um 19:04 schrieben Sie:
>
> > I didn’t try to run the build from master. I checked out the
> > release tag.
>
> The site needed to be updated without new releases in the past
> already. I didn't see how this was possible without a branch, so
> simply created one and thought it was a good idea to have one for new
> releases as well. From what I seen, Log4j has a release-2.x branch as
> well. So it might perfectly be that I didn't even consider generating
> the site based on a release tag at all.
>
> > [...]I expected
> > to see the log4cxx release version in the pom on the release tag and
> > it wasn’t there.
>
> This heavily depends on how exactly Robert created the release and
> simply needs to be debugged further. The created scripts should have
> taken care of version numbers, but might not work properly under all
> conditions or whatever. The goal was that "release_prepare" should
> have created a branch and associated tags with correct numbers to base
> releases on. In the end, "changes.xml" wasn't properly updates as well
> for some reason.
>
> So either this needs to be debugged or, as has been discussed already,
> one needs to implement new release-handling without using MVN at all.
> Though I think fixing the existing problems and/or improve docs is the
> easier way forward right now.
>
> > Once a release tag is created no modifications can
> > be made so everything needs to be correct. In Log4j I only create a
> > release branch from the tag if a patch to that release is required.
> > To date, we have never done that.
>
> When I worked last on a release years ago, things were expected to get
> changed or simply didn't work for some reason and that's only easily
> possible with a release branch in my opinion. Manually creating
> branches on each and every RC didn't seem like a good way to me.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
--
Matt Sicker <bo...@gmail.com>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Ralph Goers,
am Samstag, 22. August 2020 um 19:04 schrieben Sie:
> I didn’t try to run the build from master. I checked out the
> release tag.
The site needed to be updated without new releases in the past
already. I didn't see how this was possible without a branch, so
simply created one and thought it was a good idea to have one for new
releases as well. From what I seen, Log4j has a release-2.x branch as
well. So it might perfectly be that I didn't even consider generating
the site based on a release tag at all.
> [...]I expected
> to see the log4cxx release version in the pom on the release tag and
> it wasn’t there.
This heavily depends on how exactly Robert created the release and
simply needs to be debugged further. The created scripts should have
taken care of version numbers, but might not work properly under all
conditions or whatever. The goal was that "release_prepare" should
have created a branch and associated tags with correct numbers to base
releases on. In the end, "changes.xml" wasn't properly updates as well
for some reason.
So either this needs to be debugged or, as has been discussed already,
one needs to implement new release-handling without using MVN at all.
Though I think fixing the existing problems and/or improve docs is the
easier way forward right now.
> Once a release tag is created no modifications can
> be made so everything needs to be correct. In Log4j I only create a
> release branch from the tag if a patch to that release is required.
> To date, we have never done that.
When I worked last on a release years ago, things were expected to get
changed or simply didn't work for some reason and that's only easily
possible with a release branch in my opinion. Manually creating
branches on each and every RC didn't seem like a good way to me.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
Wow. I just noticed that it was 12 years since the last release. A little overdue I think. Great going guys. Keep up the good work!
Ralph
> On Aug 22, 2020, at 10:07 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Please disregard the last sentence below. The site must have been cached. It shows 0.11.0 now.
>
> Ralph
>
>> On Aug 22, 2020, at 10:04 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> I didn’t try to run the build from master. I checked out the release tag. The normal process with the maven release plugin is to update the version to the release version on master, create a tag, and then update the version to the next development version. The release build is then performed by checking out the tag. I expected to see the log4cxx release version in the pom on the release tag and it wasn’t there. Once a release tag is created no modifications can be made so everything needs to be correct. In Log4j I only create a release branch from the tag if a patch to that release is required. To date, we have never done that.
>>
>> As far as deploying the site goes, we deploy to a version such as 0.11.0 and then change the symlink for the current site to point to the release directory. As I understand it, that is what you did. However, when I open https://logging.apache.org/log4cxx/latest_stable/download.html <https://logging.apache.org/log4cxx/latest_stable/download.html> and the changelog page in my browser I am still seeing the site for 0.10.0.
>>
>> Ralph
>>
>>> On Aug 22, 2020, at 1:34 AM, Thorsten Schöning <tschoening@am-soft.de <ma...@am-soft.de>> wrote:
>>>
>>> Guten Tag Ralph Goers,
>>> am Freitag, 21. August 2020 um 23:42 schrieben Sie:
>>>
>>>> At this point I am not sure how to update the site.
>>>
>>> TL;DR:
>>>
>>> The site describing the latest release is not supposed to be updated
>>> from MASTER. Sources need to be merged to "latest_stable", revision
>>> numbers, release dates in e.g. "changes.xml" updated in that branch
>>> and then "mvn site-deploy" used in that branch. Afterwards links
>>> available in the SVN for sites need to be customized.
>>>
>>> I did that just now: https://logging.apache.org/log4cxx/latest_stable/ <https://logging.apache.org/log4cxx/latest_stable/>
>>>
>>> Some more details:
>>>
>>> The original release-process using MVN and the afterwards created
>>> scripts should have resulted in new branches and tags created to vote
>>> on. After that vote is accepted, the released source should be merged
>>> into the branch "latest_stable" and that branch would be the one to
>>> generate the updated site from.
>>>
>>> Using MVN to create the release, which was the approach of the past,
>>> should have handled changing version numbers everywhere according its
>>> own concepts. That leads to a new version number because of a new
>>> development cycle in MASTER and is the reason why MASTER will never be
>>> the correct place to update the released site. After the release, the
>>> version number in MASTER will always be ahead of the release.
>>>
>>> Generating a site triggers some ANT-logic to either update existing
>>> folders or create new ones in SVN based on the current version number
>>> of the project in "pom.xml". That reduces things like
>>> "0.11.0-SNAPSHOT" to "0.11.0" only and can therefore work for releases
>>> and MASTER the same time. It's only important to exec that from the
>>> correct branch to get the correct version number.
>>>
>>> That's the reason why "latest_stable" needs to be used to publish:
>>> That contains e.g. "0.11.0" after a release why MASTER contains
>>> "0.12.0-SNAPSHOT" or alike already. So generating the site with MASTER
>>> vs. "latest_stable" results in different sites available in SVN.
>>>
>>> To make handling those different directories easier, I created two
>>> links "latest_stable" and "next_stable" in the past simply targeting
>>> the corresponding directory. So after a release and after new sites
>>> have been generated, those links needs to be changed to their new
>>> targets. We currently have the following:
>>>
>>>> 0.10.0
>>>> 0.11.0
>>>> latest_stable -> 0.10.0
>>>> next_stable -> 0.11.0
>>>
>>> Which I changed to the following now:
>>>
>>>> 0.10.0
>>>> 0.11.0
>>>> 0.12.0
>>>> old_stable -> 0.10.0
>>>> latest_stable -> 0.11.0
>>>> next_stable -> 0.12.0
>>>
>>> While this all might sound a bit difficult, reason simply is that I
>>> tried to reuse as much as possible of the formerly available
>>> release-process and only automate those things that needed to be done
>>> manually in the past.
>>>
>>> Mit freundlichen Grüßen,
>>>
>>> Thorsten Schöning
>>>
>>> --
>>> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de <ma...@AM-SoFT.de>
>>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/ <http://www.am-soft.de/>
>>>
>>> Telefon...........05151- 9468- 55
>>> Fax...............05151- 9468- 88
>>> Mobil..............0178-8 9468- 04
>>>
>>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>>>
>>>
>>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
Please disregard the last sentence below. The site must have been cached. It shows 0.11.0 now.
Ralph
> On Aug 22, 2020, at 10:04 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I didn’t try to run the build from master. I checked out the release tag. The normal process with the maven release plugin is to update the version to the release version on master, create a tag, and then update the version to the next development version. The release build is then performed by checking out the tag. I expected to see the log4cxx release version in the pom on the release tag and it wasn’t there. Once a release tag is created no modifications can be made so everything needs to be correct. In Log4j I only create a release branch from the tag if a patch to that release is required. To date, we have never done that.
>
> As far as deploying the site goes, we deploy to a version such as 0.11.0 and then change the symlink for the current site to point to the release directory. As I understand it, that is what you did. However, when I open https://logging.apache.org/log4cxx/latest_stable/download.html <https://logging.apache.org/log4cxx/latest_stable/download.html> and the changelog page in my browser I am still seeing the site for 0.10.0.
>
> Ralph
>
>> On Aug 22, 2020, at 1:34 AM, Thorsten Schöning <tschoening@am-soft.de <ma...@am-soft.de>> wrote:
>>
>> Guten Tag Ralph Goers,
>> am Freitag, 21. August 2020 um 23:42 schrieben Sie:
>>
>>> At this point I am not sure how to update the site.
>>
>> TL;DR:
>>
>> The site describing the latest release is not supposed to be updated
>> from MASTER. Sources need to be merged to "latest_stable", revision
>> numbers, release dates in e.g. "changes.xml" updated in that branch
>> and then "mvn site-deploy" used in that branch. Afterwards links
>> available in the SVN for sites need to be customized.
>>
>> I did that just now: https://logging.apache.org/log4cxx/latest_stable/ <https://logging.apache.org/log4cxx/latest_stable/>
>>
>> Some more details:
>>
>> The original release-process using MVN and the afterwards created
>> scripts should have resulted in new branches and tags created to vote
>> on. After that vote is accepted, the released source should be merged
>> into the branch "latest_stable" and that branch would be the one to
>> generate the updated site from.
>>
>> Using MVN to create the release, which was the approach of the past,
>> should have handled changing version numbers everywhere according its
>> own concepts. That leads to a new version number because of a new
>> development cycle in MASTER and is the reason why MASTER will never be
>> the correct place to update the released site. After the release, the
>> version number in MASTER will always be ahead of the release.
>>
>> Generating a site triggers some ANT-logic to either update existing
>> folders or create new ones in SVN based on the current version number
>> of the project in "pom.xml". That reduces things like
>> "0.11.0-SNAPSHOT" to "0.11.0" only and can therefore work for releases
>> and MASTER the same time. It's only important to exec that from the
>> correct branch to get the correct version number.
>>
>> That's the reason why "latest_stable" needs to be used to publish:
>> That contains e.g. "0.11.0" after a release why MASTER contains
>> "0.12.0-SNAPSHOT" or alike already. So generating the site with MASTER
>> vs. "latest_stable" results in different sites available in SVN.
>>
>> To make handling those different directories easier, I created two
>> links "latest_stable" and "next_stable" in the past simply targeting
>> the corresponding directory. So after a release and after new sites
>> have been generated, those links needs to be changed to their new
>> targets. We currently have the following:
>>
>>> 0.10.0
>>> 0.11.0
>>> latest_stable -> 0.10.0
>>> next_stable -> 0.11.0
>>
>> Which I changed to the following now:
>>
>>> 0.10.0
>>> 0.11.0
>>> 0.12.0
>>> old_stable -> 0.10.0
>>> latest_stable -> 0.11.0
>>> next_stable -> 0.12.0
>>
>> While this all might sound a bit difficult, reason simply is that I
>> tried to reuse as much as possible of the formerly available
>> release-process and only automate those things that needed to be done
>> manually in the past.
>>
>> Mit freundlichen Grüßen,
>>
>> Thorsten Schöning
>>
>> --
>> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de <ma...@AM-SoFT.de>
>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/ <http://www.am-soft.de/>
>>
>> Telefon...........05151- 9468- 55
>> Fax...............05151- 9468- 88
>> Mobil..............0178-8 9468- 04
>>
>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>>
>>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I didn’t try to run the build from master. I checked out the release tag. The normal process with the maven release plugin is to update the version to the release version on master, create a tag, and then update the version to the next development version. The release build is then performed by checking out the tag. I expected to see the log4cxx release version in the pom on the release tag and it wasn’t there. Once a release tag is created no modifications can be made so everything needs to be correct. In Log4j I only create a release branch from the tag if a patch to that release is required. To date, we have never done that.
As far as deploying the site goes, we deploy to a version such as 0.11.0 and then change the symlink for the current site to point to the release directory. As I understand it, that is what you did. However, when I open https://logging.apache.org/log4cxx/latest_stable/download.html <https://logging.apache.org/log4cxx/latest_stable/download.html> and the changelog page in my browser I am still seeing the site for 0.10.0.
Ralph
> On Aug 22, 2020, at 1:34 AM, Thorsten Schöning <ts...@am-soft.de> wrote:
>
> Guten Tag Ralph Goers,
> am Freitag, 21. August 2020 um 23:42 schrieben Sie:
>
>> At this point I am not sure how to update the site.
>
> TL;DR:
>
> The site describing the latest release is not supposed to be updated
> from MASTER. Sources need to be merged to "latest_stable", revision
> numbers, release dates in e.g. "changes.xml" updated in that branch
> and then "mvn site-deploy" used in that branch. Afterwards links
> available in the SVN for sites need to be customized.
>
> I did that just now: https://logging.apache.org/log4cxx/latest_stable/
>
> Some more details:
>
> The original release-process using MVN and the afterwards created
> scripts should have resulted in new branches and tags created to vote
> on. After that vote is accepted, the released source should be merged
> into the branch "latest_stable" and that branch would be the one to
> generate the updated site from.
>
> Using MVN to create the release, which was the approach of the past,
> should have handled changing version numbers everywhere according its
> own concepts. That leads to a new version number because of a new
> development cycle in MASTER and is the reason why MASTER will never be
> the correct place to update the released site. After the release, the
> version number in MASTER will always be ahead of the release.
>
> Generating a site triggers some ANT-logic to either update existing
> folders or create new ones in SVN based on the current version number
> of the project in "pom.xml". That reduces things like
> "0.11.0-SNAPSHOT" to "0.11.0" only and can therefore work for releases
> and MASTER the same time. It's only important to exec that from the
> correct branch to get the correct version number.
>
> That's the reason why "latest_stable" needs to be used to publish:
> That contains e.g. "0.11.0" after a release why MASTER contains
> "0.12.0-SNAPSHOT" or alike already. So generating the site with MASTER
> vs. "latest_stable" results in different sites available in SVN.
>
> To make handling those different directories easier, I created two
> links "latest_stable" and "next_stable" in the past simply targeting
> the corresponding directory. So after a release and after new sites
> have been generated, those links needs to be changed to their new
> targets. We currently have the following:
>
>> 0.10.0
>> 0.11.0
>> latest_stable -> 0.10.0
>> next_stable -> 0.11.0
>
> Which I changed to the following now:
>
>> 0.10.0
>> 0.11.0
>> 0.12.0
>> old_stable -> 0.10.0
>> latest_stable -> 0.11.0
>> next_stable -> 0.12.0
>
> While this all might sound a bit difficult, reason simply is that I
> tried to reuse as much as possible of the formerly available
> release-process and only automate those things that needed to be done
> manually in the past.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Ralph Goers,
am Freitag, 21. August 2020 um 23:42 schrieben Sie:
> At this point I am not sure how to update the site.
TL;DR:
The site describing the latest release is not supposed to be updated
from MASTER. Sources need to be merged to "latest_stable", revision
numbers, release dates in e.g. "changes.xml" updated in that branch
and then "mvn site-deploy" used in that branch. Afterwards links
available in the SVN for sites need to be customized.
I did that just now: https://logging.apache.org/log4cxx/latest_stable/
Some more details:
The original release-process using MVN and the afterwards created
scripts should have resulted in new branches and tags created to vote
on. After that vote is accepted, the released source should be merged
into the branch "latest_stable" and that branch would be the one to
generate the updated site from.
Using MVN to create the release, which was the approach of the past,
should have handled changing version numbers everywhere according its
own concepts. That leads to a new version number because of a new
development cycle in MASTER and is the reason why MASTER will never be
the correct place to update the released site. After the release, the
version number in MASTER will always be ahead of the release.
Generating a site triggers some ANT-logic to either update existing
folders or create new ones in SVN based on the current version number
of the project in "pom.xml". That reduces things like
"0.11.0-SNAPSHOT" to "0.11.0" only and can therefore work for releases
and MASTER the same time. It's only important to exec that from the
correct branch to get the correct version number.
That's the reason why "latest_stable" needs to be used to publish:
That contains e.g. "0.11.0" after a release why MASTER contains
"0.12.0-SNAPSHOT" or alike already. So generating the site with MASTER
vs. "latest_stable" results in different sites available in SVN.
To make handling those different directories easier, I created two
links "latest_stable" and "next_stable" in the past simply targeting
the corresponding directory. So after a release and after new sites
have been generated, those links needs to be changed to their new
targets. We currently have the following:
> 0.10.0
> 0.11.0
> latest_stable -> 0.10.0
> next_stable -> 0.11.0
Which I changed to the following now:
> 0.10.0
> 0.11.0
> 0.12.0
> old_stable -> 0.10.0
> latest_stable -> 0.11.0
> next_stable -> 0.12.0
While this all might sound a bit difficult, reason simply is that I
tried to reuse as much as possible of the formerly available
release-process and only automate those things that needed to be done
manually in the past.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I tried running mvn site for log4cxx and it failed. Since the pom is still 0.11.0-SNAPSHOT everything that refers to the version would be wrong. If I just patch the download page then the changes page won’t reflect whatever was done in 0.11.0. I also noticed that the source links are pointing to gitbox. Is that desired or should they point to GitHub?
At this point I am not sure how to update the site.
Thoughts?
Ralph
> On Aug 21, 2020, at 2:18 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I have moved the files to the release folder. I will look at updating the web site.
>
> Ralph
>
>> On Aug 18, 2020, at 4:49 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> I’ll take care of it.
>>
>> Ralph
>>
>>> On Aug 18, 2020, at 3:46 PM, Robert Middleton <os...@gmail.com> wrote:
>>>
>>> By my count at this point, that means we have 3 binding +1 votes from
>>> Ralph, Christian, Remko; and +1 votes from Thorsten and Stephen.
>>>
>>> Ralph, do you want to upload to the releases repo with the fix for the .sha
>>> file, or do you want me to do that?(it is a SHA-512, it's just named
>>> incorrectly)
>>>
>>> -Robert Middleton
>>>
>>> On Mon, Aug 17, 2020 at 5:47 AM Stephen Webb <sw...@gmail.com> wrote:
>>>
>>>> I am using a recent version in production Ubuntu servers, so it is
>>>> definitely release ready.
>>>> +1
>>>>
>>>> On Mon, Aug 17, 2020, 7:27 PM Christian Grobmeier <gr...@apache.org>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am not an expert on c++ or something, but I looked on the content, read
>>>>> this thread and think it is safe to release this. However, my hope is
>>>> that
>>>>> in future more competent cxx devs than me would check it :)
>>>>>
>>>>> I vote +1 also
>>>>>
>>>>> Cheers,
>>>>> Christian
>>>>>
>>>>> On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote:
>>>>>> I noticed that the files have she and md5 files. We are not supposed to
>>>>>> use either of these any more and only use sha512. I can fix that.
>>>>>>
>>>>>> I vote +1
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> I've run through the release of log4cxx 0.11.0. There's still
>>>>> something
>>>>>>> strange about how it all works(mostly due to the tooling of shell
>>>>>>> script/maven/ant/cmake/autotools). However, I do believe that I
>>>> have a
>>>>>>> workable release at this point. A quick note on the release: I did
>>>> the
>>>>>>> 'mvn release:prepare' manually, which is where these artifacts come
>>>>> from;
>>>>>>> running through the 'mvn release:perform' causes the generated files
>>>>> to be
>>>>>>> -SNAPSHOT versioned, instead of 0.11.0. This means that the version
>>>>> of the
>>>>>>> pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't
>>>>> really
>>>>>>> used to build I don't think this will be an issue.
>>>>>>>
>>>>>>> Artifacts uploaded here:
>>>>>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>>>>>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>>>>>>>
>>>>>>> The artifacts are signed, although I still need to send my key to
>>>> Matt
>>>>> so
>>>>>>> he can import it into the logging KEYS file.
>>>>>>>
>>>>>>> -Robert Middleton
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>>
>
>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I have moved the files to the release folder. I will look at updating the web site.
Ralph
> On Aug 18, 2020, at 4:49 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I’ll take care of it.
>
> Ralph
>
>> On Aug 18, 2020, at 3:46 PM, Robert Middleton <os...@gmail.com> wrote:
>>
>> By my count at this point, that means we have 3 binding +1 votes from
>> Ralph, Christian, Remko; and +1 votes from Thorsten and Stephen.
>>
>> Ralph, do you want to upload to the releases repo with the fix for the .sha
>> file, or do you want me to do that?(it is a SHA-512, it's just named
>> incorrectly)
>>
>> -Robert Middleton
>>
>> On Mon, Aug 17, 2020 at 5:47 AM Stephen Webb <sw...@gmail.com> wrote:
>>
>>> I am using a recent version in production Ubuntu servers, so it is
>>> definitely release ready.
>>> +1
>>>
>>> On Mon, Aug 17, 2020, 7:27 PM Christian Grobmeier <gr...@apache.org>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am not an expert on c++ or something, but I looked on the content, read
>>>> this thread and think it is safe to release this. However, my hope is
>>> that
>>>> in future more competent cxx devs than me would check it :)
>>>>
>>>> I vote +1 also
>>>>
>>>> Cheers,
>>>> Christian
>>>>
>>>> On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote:
>>>>> I noticed that the files have she and md5 files. We are not supposed to
>>>>> use either of these any more and only use sha512. I can fix that.
>>>>>
>>>>> I vote +1
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>> I've run through the release of log4cxx 0.11.0. There's still
>>>> something
>>>>>> strange about how it all works(mostly due to the tooling of shell
>>>>>> script/maven/ant/cmake/autotools). However, I do believe that I
>>> have a
>>>>>> workable release at this point. A quick note on the release: I did
>>> the
>>>>>> 'mvn release:prepare' manually, which is where these artifacts come
>>>> from;
>>>>>> running through the 'mvn release:perform' causes the generated files
>>>> to be
>>>>>> -SNAPSHOT versioned, instead of 0.11.0. This means that the version
>>>> of the
>>>>>> pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't
>>>> really
>>>>>> used to build I don't think this will be an issue.
>>>>>>
>>>>>> Artifacts uploaded here:
>>>>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>>>>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>>>>>>
>>>>>> The artifacts are signed, although I still need to send my key to
>>> Matt
>>>> so
>>>>>> he can import it into the logging KEYS file.
>>>>>>
>>>>>> -Robert Middleton
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I’ll take care of it.
Ralph
> On Aug 18, 2020, at 3:46 PM, Robert Middleton <os...@gmail.com> wrote:
>
> By my count at this point, that means we have 3 binding +1 votes from
> Ralph, Christian, Remko; and +1 votes from Thorsten and Stephen.
>
> Ralph, do you want to upload to the releases repo with the fix for the .sha
> file, or do you want me to do that?(it is a SHA-512, it's just named
> incorrectly)
>
> -Robert Middleton
>
> On Mon, Aug 17, 2020 at 5:47 AM Stephen Webb <sw...@gmail.com> wrote:
>
>> I am using a recent version in production Ubuntu servers, so it is
>> definitely release ready.
>> +1
>>
>> On Mon, Aug 17, 2020, 7:27 PM Christian Grobmeier <gr...@apache.org>
>> wrote:
>>
>>> Hello,
>>>
>>> I am not an expert on c++ or something, but I looked on the content, read
>>> this thread and think it is safe to release this. However, my hope is
>> that
>>> in future more competent cxx devs than me would check it :)
>>>
>>> I vote +1 also
>>>
>>> Cheers,
>>> Christian
>>>
>>> On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote:
>>>> I noticed that the files have she and md5 files. We are not supposed to
>>>> use either of these any more and only use sha512. I can fix that.
>>>>
>>>> I vote +1
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>
>>>>> On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com>
>>> wrote:
>>>>>
>>>>> I've run through the release of log4cxx 0.11.0. There's still
>>> something
>>>>> strange about how it all works(mostly due to the tooling of shell
>>>>> script/maven/ant/cmake/autotools). However, I do believe that I
>> have a
>>>>> workable release at this point. A quick note on the release: I did
>> the
>>>>> 'mvn release:prepare' manually, which is where these artifacts come
>>> from;
>>>>> running through the 'mvn release:perform' causes the generated files
>>> to be
>>>>> -SNAPSHOT versioned, instead of 0.11.0. This means that the version
>>> of the
>>>>> pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't
>>> really
>>>>> used to build I don't think this will be an issue.
>>>>>
>>>>> Artifacts uploaded here:
>>>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>>>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>>>>>
>>>>> The artifacts are signed, although I still need to send my key to
>> Matt
>>> so
>>>>> he can import it into the logging KEYS file.
>>>>>
>>>>> -Robert Middleton
>>>>
>>>>
>>>>
>>>
>>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Robert Middleton <os...@gmail.com>.
By my count at this point, that means we have 3 binding +1 votes from
Ralph, Christian, Remko; and +1 votes from Thorsten and Stephen.
Ralph, do you want to upload to the releases repo with the fix for the .sha
file, or do you want me to do that?(it is a SHA-512, it's just named
incorrectly)
-Robert Middleton
On Mon, Aug 17, 2020 at 5:47 AM Stephen Webb <sw...@gmail.com> wrote:
> I am using a recent version in production Ubuntu servers, so it is
> definitely release ready.
> +1
>
> On Mon, Aug 17, 2020, 7:27 PM Christian Grobmeier <gr...@apache.org>
> wrote:
>
> > Hello,
> >
> > I am not an expert on c++ or something, but I looked on the content, read
> > this thread and think it is safe to release this. However, my hope is
> that
> > in future more competent cxx devs than me would check it :)
> >
> > I vote +1 also
> >
> > Cheers,
> > Christian
> >
> > On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote:
> > > I noticed that the files have she and md5 files. We are not supposed to
> > > use either of these any more and only use sha512. I can fix that.
> > >
> > > I vote +1
> > >
> > > Ralph
> > >
> > >
> > >
> > >
> > > > On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com>
> > wrote:
> > > >
> > > > I've run through the release of log4cxx 0.11.0. There's still
> > something
> > > > strange about how it all works(mostly due to the tooling of shell
> > > > script/maven/ant/cmake/autotools). However, I do believe that I
> have a
> > > > workable release at this point. A quick note on the release: I did
> the
> > > > 'mvn release:prepare' manually, which is where these artifacts come
> > from;
> > > > running through the 'mvn release:perform' causes the generated files
> > to be
> > > > -SNAPSHOT versioned, instead of 0.11.0. This means that the version
> > of the
> > > > pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't
> > really
> > > > used to build I don't think this will be an issue.
> > > >
> > > > Artifacts uploaded here:
> > > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> > > > tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
> > > >
> > > > The artifacts are signed, although I still need to send my key to
> Matt
> > so
> > > > he can import it into the logging KEYS file.
> > > >
> > > > -Robert Middleton
> > >
> > >
> > >
> >
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Stephen Webb <sw...@gmail.com>.
I am using a recent version in production Ubuntu servers, so it is
definitely release ready.
+1
On Mon, Aug 17, 2020, 7:27 PM Christian Grobmeier <gr...@apache.org>
wrote:
> Hello,
>
> I am not an expert on c++ or something, but I looked on the content, read
> this thread and think it is safe to release this. However, my hope is that
> in future more competent cxx devs than me would check it :)
>
> I vote +1 also
>
> Cheers,
> Christian
>
> On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote:
> > I noticed that the files have she and md5 files. We are not supposed to
> > use either of these any more and only use sha512. I can fix that.
> >
> > I vote +1
> >
> > Ralph
> >
> >
> >
> >
> > > On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com>
> wrote:
> > >
> > > I've run through the release of log4cxx 0.11.0. There's still
> something
> > > strange about how it all works(mostly due to the tooling of shell
> > > script/maven/ant/cmake/autotools). However, I do believe that I have a
> > > workable release at this point. A quick note on the release: I did the
> > > 'mvn release:prepare' manually, which is where these artifacts come
> from;
> > > running through the 'mvn release:perform' causes the generated files
> to be
> > > -SNAPSHOT versioned, instead of 0.11.0. This means that the version
> of the
> > > pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't
> really
> > > used to build I don't think this will be an issue.
> > >
> > > Artifacts uploaded here:
> > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> > > tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
> > >
> > > The artifacts are signed, although I still need to send my key to Matt
> so
> > > he can import it into the logging KEYS file.
> > >
> > > -Robert Middleton
> >
> >
> >
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Christian Grobmeier <gr...@apache.org>.
Hello,
I am not an expert on c++ or something, but I looked on the content, read this thread and think it is safe to release this. However, my hope is that in future more competent cxx devs than me would check it :)
I vote +1 also
Cheers,
Christian
On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote:
> I noticed that the files have she and md5 files. We are not supposed to
> use either of these any more and only use sha512. I can fix that.
>
> I vote +1
>
> Ralph
>
>
>
>
> > On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com> wrote:
> >
> > I've run through the release of log4cxx 0.11.0. There's still something
> > strange about how it all works(mostly due to the tooling of shell
> > script/maven/ant/cmake/autotools). However, I do believe that I have a
> > workable release at this point. A quick note on the release: I did the
> > 'mvn release:prepare' manually, which is where these artifacts come from;
> > running through the 'mvn release:perform' causes the generated files to be
> > -SNAPSHOT versioned, instead of 0.11.0. This means that the version of the
> > pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't really
> > used to build I don't think this will be an issue.
> >
> > Artifacts uploaded here:
> > https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> > tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
> >
> > The artifacts are signed, although I still need to send my key to Matt so
> > he can import it into the logging KEYS file.
> >
> > -Robert Middleton
>
>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Ralph Goers,
am Montag, 17. August 2020 um 08:08 schrieben Sie:
> I noticed that the files have she and md5 files. We are not
> supposed to use either of these any more and only use sha512. I can fix that.
While the file extension is named ".sha", SHA-512 is calculated
already:
> gpg -ab --yes "${file}" > "${file}.asc"
> md5sum "${file}" > "${file}.md5"
> sha512sum "${file}" > "${file}.sha"
So only the extension needs to be changed to whatever you prefer and
optionally MD5 removed.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I noticed that the files have she and md5 files. We are not supposed to use either of these any more and only use sha512. I can fix that.
I vote +1
Ralph
> On Aug 9, 2020, at 10:24 AM, Robert Middleton <os...@gmail.com> wrote:
>
> I've run through the release of log4cxx 0.11.0. There's still something
> strange about how it all works(mostly due to the tooling of shell
> script/maven/ant/cmake/autotools). However, I do believe that I have a
> workable release at this point. A quick note on the release: I did the
> 'mvn release:prepare' manually, which is where these artifacts come from;
> running through the 'mvn release:perform' causes the generated files to be
> -SNAPSHOT versioned, instead of 0.11.0. This means that the version of the
> pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't really
> used to build I don't think this will be an issue.
>
> Artifacts uploaded here:
> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>
> The artifacts are signed, although I still need to send my key to Matt so
> he can import it into the logging KEYS file.
>
> -Robert Middleton
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Robert Middleton,
am Donnerstag, 13. August 2020 um 05:52 schrieben Sie:
> [...]Windows has 8 failures(some are timeout, some have to
> do with encoding, and possibly some other issues as well). At this point
> that makes me much less confident in everything working properly, so
> perhaps it is best to fix those issues first.
Those errors are most likely only related to CMAKE and wrong test
setup, not the code base itself. CMAKE didn't work properly OOB for me
as well[1], but testing the code base with my non-CMAKE projects on
Windows works properly. OTOH, you said that CMAKE built successfully
on your Windows.
So you could easily argue that most users don't use Windows and all
others will benefit from a release, that the current release won't
be free of bugs anyway and that even if you fix the concrete issues
with GitHub actions, some short time afterwards someone WILL issue a
new bug in ones Windows environment. :-)
In my opinion, those problems are NOT a reason to not release. As more
people are looking into the release, the more discussions will arise
about "things". This happened in the past already as well. Remember
that only some days ago someone said that releases don't need to be
perfect at all. I regularly find issues in released, tested etc.
software, that's day-to-day business and shouldn't prevent this
release as well.
[1]: https://issues.apache.org/jira/browse/LOGCXX-510
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Robert Middleton <os...@gmail.com>.
Ralph,
Thanks for taking a look at it whenever you get a chance.
Also to note: I did manage to get it building via Github actions, and while
Linux(Ubuntu) works fine, OSX has one test failure(the same that you saw
the other week), and Windows has 8 failures(some are timeout, some have to
do with encoding, and possibly some other issues as well). At this point
that makes me much less confident in everything working properly, so
perhaps it is best to fix those issues first.
-Robert Middleton
On Wed, Aug 12, 2020 at 10:01 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> Yeah - ideally this would be done within 72 hours but that doesn’t always
> happen - especially since this is the first release in a long, long time.
> I have been planning on reviewing it but probably can’t get to it until
> tomorrow.
>
> Ralph
>
> > On Aug 12, 2020, at 6:34 PM, Robert Middleton <os...@gmail.com>
> wrote:
> >
> > So I realize that I never set a normal time for this vote to be open, but
> > it has been 72 hours at this point. Do people still need more time to
> > validate, or are there some issues that need to be resolved first?
> >
> > -Robert Middleton
> >
> > On Mon, Aug 10, 2020 at 5:49 PM Remko Popma <re...@gmail.com>
> wrote:
> >
> >> +1
> >> Remko.
> >>
> >>
> >>
> >>
> >>> On Aug 11, 2020, at 6:27, Robert Middleton <os...@gmail.com>
> wrote:
> >>>
> >>> This new RC has the latest fixes that we've done(LOG4CXX-512,490,398).
> >>>
> >>> I'm not sure exactly why the autotools are there now; something about
> >> doing
> >>> the maven release triggers them. I don't think they get generated
> until
> >>> after the website gets uploaded, which I couldn't do before. They
> >> /should/
> >>> be there in general, as that's the normal way to configure the
> >>> project(unless you are checking out the source code directly).
> >>>
> >>> -Robert Middleton
> >>>
> >>>> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning <
> >> tschoening@am-soft.de>
> >>>> wrote:
> >>>>
> >>>> Guten Tag Robert Middleton,
> >>>> am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
> >>>>
> >>>>> Artifacts uploaded here:
> >>>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> >>>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
> >>>>
> >>>> +1 for me.
> >>>>
> >>>> Do you know what's the difference compared to what you have uploaded
> >>>> last time in the thread about test release? The current archives
> >>>> contain more individual autotools-files. Did you simply execute
> >>>> "autogen.sh" this time compared to the last?
> >>>>
> >>>> Mit freundlichen Grüßen,
> >>>>
> >>>> Thorsten Schöning
> >>>>
> >>>> --
> >>>> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> >>>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
> >>>>
> >>>> Telefon...........05151- 9468- 55
> >>>> Fax...............05151- 9468- 88
> >>>> Mobil..............0178-8 9468- 04
> >>>>
> >>>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> >>>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> >>>>
> >>>>
> >>
>
>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Ralph Goers <ra...@dslextreme.com>.
Yeah - ideally this would be done within 72 hours but that doesn’t always happen - especially since this is the first release in a long, long time. I have been planning on reviewing it but probably can’t get to it until tomorrow.
Ralph
> On Aug 12, 2020, at 6:34 PM, Robert Middleton <os...@gmail.com> wrote:
>
> So I realize that I never set a normal time for this vote to be open, but
> it has been 72 hours at this point. Do people still need more time to
> validate, or are there some issues that need to be resolved first?
>
> -Robert Middleton
>
> On Mon, Aug 10, 2020 at 5:49 PM Remko Popma <re...@gmail.com> wrote:
>
>> +1
>> Remko.
>>
>>
>>
>>
>>> On Aug 11, 2020, at 6:27, Robert Middleton <os...@gmail.com> wrote:
>>>
>>> This new RC has the latest fixes that we've done(LOG4CXX-512,490,398).
>>>
>>> I'm not sure exactly why the autotools are there now; something about
>> doing
>>> the maven release triggers them. I don't think they get generated until
>>> after the website gets uploaded, which I couldn't do before. They
>> /should/
>>> be there in general, as that's the normal way to configure the
>>> project(unless you are checking out the source code directly).
>>>
>>> -Robert Middleton
>>>
>>>> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning <
>> tschoening@am-soft.de>
>>>> wrote:
>>>>
>>>> Guten Tag Robert Middleton,
>>>> am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
>>>>
>>>>> Artifacts uploaded here:
>>>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>>>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>>>>
>>>> +1 for me.
>>>>
>>>> Do you know what's the difference compared to what you have uploaded
>>>> last time in the thread about test release? The current archives
>>>> contain more individual autotools-files. Did you simply execute
>>>> "autogen.sh" this time compared to the last?
>>>>
>>>> Mit freundlichen Grüßen,
>>>>
>>>> Thorsten Schöning
>>>>
>>>> --
>>>> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
>>>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>>>>
>>>> Telefon...........05151- 9468- 55
>>>> Fax...............05151- 9468- 88
>>>> Mobil..............0178-8 9468- 04
>>>>
>>>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>>>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>>>>
>>>>
>>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Robert Middleton <os...@gmail.com>.
So I realize that I never set a normal time for this vote to be open, but
it has been 72 hours at this point. Do people still need more time to
validate, or are there some issues that need to be resolved first?
-Robert Middleton
On Mon, Aug 10, 2020 at 5:49 PM Remko Popma <re...@gmail.com> wrote:
> +1
> Remko.
>
>
>
>
> > On Aug 11, 2020, at 6:27, Robert Middleton <os...@gmail.com> wrote:
> >
> > This new RC has the latest fixes that we've done(LOG4CXX-512,490,398).
> >
> > I'm not sure exactly why the autotools are there now; something about
> doing
> > the maven release triggers them. I don't think they get generated until
> > after the website gets uploaded, which I couldn't do before. They
> /should/
> > be there in general, as that's the normal way to configure the
> > project(unless you are checking out the source code directly).
> >
> > -Robert Middleton
> >
> >> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning <
> tschoening@am-soft.de>
> >> wrote:
> >>
> >> Guten Tag Robert Middleton,
> >> am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
> >>
> >>> Artifacts uploaded here:
> >>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> >>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
> >>
> >> +1 for me.
> >>
> >> Do you know what's the difference compared to what you have uploaded
> >> last time in the thread about test release? The current archives
> >> contain more individual autotools-files. Did you simply execute
> >> "autogen.sh" this time compared to the last?
> >>
> >> Mit freundlichen Grüßen,
> >>
> >> Thorsten Schöning
> >>
> >> --
> >> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> >> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
> >>
> >> Telefon...........05151- 9468- 55
> >> Fax...............05151- 9468- 88
> >> Mobil..............0178-8 9468- 04
> >>
> >> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> >> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> >>
> >>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Remko Popma <re...@gmail.com>.
+1
Remko.
> On Aug 11, 2020, at 6:27, Robert Middleton <os...@gmail.com> wrote:
>
> This new RC has the latest fixes that we've done(LOG4CXX-512,490,398).
>
> I'm not sure exactly why the autotools are there now; something about doing
> the maven release triggers them. I don't think they get generated until
> after the website gets uploaded, which I couldn't do before. They /should/
> be there in general, as that's the normal way to configure the
> project(unless you are checking out the source code directly).
>
> -Robert Middleton
>
>> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning <ts...@am-soft.de>
>> wrote:
>>
>> Guten Tag Robert Middleton,
>> am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
>>
>>> Artifacts uploaded here:
>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>>
>> +1 for me.
>>
>> Do you know what's the difference compared to what you have uploaded
>> last time in the thread about test release? The current archives
>> contain more individual autotools-files. Did you simply execute
>> "autogen.sh" this time compared to the last?
>>
>> Mit freundlichen Grüßen,
>>
>> Thorsten Schöning
>>
>> --
>> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>>
>> Telefon...........05151- 9468- 55
>> Fax...............05151- 9468- 88
>> Mobil..............0178-8 9468- 04
>>
>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>>
>>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Robert Middleton <os...@gmail.com>.
This new RC has the latest fixes that we've done(LOG4CXX-512,490,398).
I'm not sure exactly why the autotools are there now; something about doing
the maven release triggers them. I don't think they get generated until
after the website gets uploaded, which I couldn't do before. They /should/
be there in general, as that's the normal way to configure the
project(unless you are checking out the source code directly).
-Robert Middleton
On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning <ts...@am-soft.de>
wrote:
> Guten Tag Robert Middleton,
> am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
>
> > Artifacts uploaded here:
> > https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> > tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>
> +1 for me.
>
> Do you know what's the difference compared to what you have uploaded
> last time in the thread about test release? The current archives
> contain more individual autotools-files. Did you simply execute
> "autogen.sh" this time compared to the last?
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Robert Middleton,
am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
> Artifacts uploaded here:
> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
+1 for me.
Do you know what's the difference compared to what you have uploaded
last time in the thread about test release? The current archives
contain more individual autotools-files. Did you simply execute
"autogen.sh" this time compared to the last?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow