Am 2020-11-23 um 18:50 schrieb Oleg Kalnichevski:
On Mon, 2020-11-23 at 12:53 +0100, Michael Osipov wrote:
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?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
