On Tue, 2020-11-24 at 21:23 +0100, Michael Osipov wrote: ...
> > So, we would go back to the days when fixing a typo in the logging > > guide required a new release and a release vote? I remember those > > days > > with great "fondness". > > > > Do we have to move hand-written content back to projects that > > require a > > release vote simply to work around some limitations of the maven > > site > > plugin? In this case I would rather lose reports that individual > > projects contribute to the web site. > > Strictly speaking yes, but I don't want that. What I will do in a > test > is to move everything out of httpcomponents-X-Y to guides/, > examples/, > etc which will make you flexible again. Those files are not tied to > patch releases at all and mostly to major/minor ones. They can easily > be > consolidated. > > Stay tuned... > > Michael > Hi Michael I have a proposal that works quite complimentary to what you have been doing: 1. during the release process we publish release specific reports to the maven repository as a separate artifact. Ex: `httpcore-4.4.14- reports.zip` I personally find only javadocs and clirr reports useful. The rest are pretty useless in my opinion but I am fine with including other reports as well. 2. The website project can pull those reports out of the maven repository and add those reports to the project web site content (most likely as sub-directories: httpcore-4.4.14-reports.zip -> http://hc.apache.org/httpcore-4.4.14/reports/) * 3. The process of website publishing is fully self-contained and independent of any individual release and release vote. Any number of released components can contribute their reports to the project website at any point of time. * this will likely require a custom Maven plugin which I am willing to build and if there is interest contribute to the Maven ecosystem. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
