On Sun, 2020-11-22 at 20:44 +0100, Michael Osipov wrote: > Am 2020-11-22 um 20:16 schrieb Oleg Kalnichevski: > > On Sun, 2020-11-22 at 20:11 +0100, Oleg Kalnichevski wrote: > > > On Sun, 2020-11-22 at 20:04 +0100, Michael Osipov wrote: > > > > > > ... > > > > > > > > Wait a second. I am not sure what release vote you are > > > > > referring > > > > > to. > > > > > Web site publishing is not subject to any kind of vote. > > > > > > > > I was not talking about website vote, but about a release vote, > > > > e.g., > > > > core 4/5, client 4/5. Along with that staged release there goes > > > > a > > > > staged > > > > site. See this vote: > > > > http://mail-archives.apache.org/mod_mbox/maven-dev/202011.mbox/%3C6d098deb-00ab-ec01-1c0f-73748462d521%40apache.org%3E > > > > > > > > When the vote passes for the release, you complete the staged > > > > release > > > > as > > > > well as promote the staged site. > > > > > > > > Is that better? > > > > > > > > > > I am not sure. Web site publishing should not be related to any > > > vote > > > at > > > all. I should be able to take any officially released artifact > > > and > > > republish its content at any point of time, add more content or > > > fix > > > things. That should never require a new release of any sort. > > > > > > > In other words one should be able to contribute new content to an > > already released component, say, a performance optimization guide, > > submit a PR against the web site project and a committer should be > > able > > to review the PR, hit merge and get the damn thing published > > immediately. > > Let's split site and components logically. > > site: Every change in master will go almost immediately online right > now > since we have a Jenkins job right now. Try it out and you'll see. > components: They are considered to be published with a release > cadence, > but the steps I have described can be performed at anytime from > master > or branch w/o any release. What you have to bear in mind that > currently > neither core nor client have any handwritten content and since the > top > bar contains the current version from a user's POV, this will be > weird > because it will tell 5.1-beta2-SNAPSHOT and if code has changed you > will > inadvertly publish updated Javadoc which will even more cause > confusion. > I wouldn't do that. If really necessary I would recomment to switch > to > the tag apply the changes locally and publish the site, but this > stil > would be ugly because user's wouldn't see this content in the Git > repo > associated with this tag. We at Maven avoid such situations. > > My advise is to bundle documentation when it is tightly coupled to > it > from release to release with a component otherwise this should live > in > httpcomponents-website. > > For instance, at Maven we have guides [1] on the website, not in the > components. > > Does it clear up the situation? >
As long as project specific hand-written content stays in httpcomponents-website (like it is now) and individual projects only contribute release specific reports (javadocs, etc) I am fine with that. I might be mistaken but I thought it was proposed to move project specific hand-written content to the project repositories. That would be a big step back in my opinion. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
