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 <ralph.go...@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 <tschoen...@am-soft.de >> <mailto:tschoen...@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.schoen...@am-soft.de >> <mailto:thorsten.schoen...@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 >> >> >
