Am 2020-11-22 um 23:09 schrieb Oleg Kalnichevski:
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.
It is problematic to have the same subtree twice. It will simply not
work. I would at least move the index.apt to the subproject and
consolidate the rest in guides or examples of of the component trees.
The content you have mentioned does not change that often which requires
an out of release modification. If that is really necessary you can
still generate the site and just manually commit that specific HTML
file. We at Maven do get report on incorrect component documentation,
but this is always addressed with releases. No one ever complained that
this hasn't been published immediately.
I will pick up Hervé's proposal of content and components subdirs and
will restructure. This will leave the current entire site intact and we
can evaluate, decide and complete the new approach.
Is that acceptable?
M
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
