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?
M
[1] https://svn.apache.org/repos/asf/maven/website/content/guides/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
