[
https://issues.apache.org/jira/browse/RATIS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625977#comment-16625977
]
Josh Elser commented on RATIS-316:
----------------------------------
{quote}Can we upload fixed version to the apache nexus without release votes?
Isn't it a violation of the ASF release policy?
{quote}
It's just a SNAPSHOT build – no different than how we do development builds
now. Long term, yes, we need to go through the official release process for the
ratis-thirdparty artifact (see my comment above about me taking that on next).
{quote}How will we release apache ratis? We need to publish the sources, but
with this approach we need to publish the sources from both of the
repositories. Is it right? What will be the strategy to handle LICENSE/NOTICE
files?
{quote}
The whole point is that _nothing_ has to change for Apache Ratis releases. We
will handle all licensing and releasing for the thirdparty artifact separately
which keeps the normal Ratis release process much easier. The only complication
is when a new version of Netty, Grpc, or other thirdparty artifact is needed by
Ratis, we have a slightly longer cadence to get this into the Ratis build
because we would have to go through the release process. Like the state now, we
can temporarily depend on a SNAPSHOT build of ratis-thirdparty.
Does this help explain how it can work? I promise, this is all above-board :)
> Centralize shaded thirdparty dependencies in a single artifact
> --------------------------------------------------------------
>
> Key: RATIS-316
> URL: https://issues.apache.org/jira/browse/RATIS-316
> Project: Ratis
> Issue Type: Improvement
> Components: build
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Major
> Attachments: RATIS-316.003.patch
>
>
> After the changes in RATIS-288, developers may find that their IDEs are
> complaining about dependencies that we bundle in ratis-proto-shaded as not
> being "found".
> This is understandable because IDEs typically aren't smart enough to follow
> the maven-shade-plugin and unravel the relocation that's happening.
> The easiest solution for this is to make an artifact for our "thirdparty"
> dependencies that has its own release schedule. The "core" of Ratis can then
> depend on this artifact and the relocated dependencies in the well-known
> location (fix the IDE errors). Additionally, this will give us a bit more
> flexibility in upgrading to newer versions of these dependencies without
> having to re-release Ratis (e.g. if there is a CVE on Netty, we can make a
> new release of ratis-thirdparty without re-releasing Ratis just for that
> change).
> We could move this to a separate git repo, but it's easy enough to just leave
> this is a sub-directory of ratis.git. I don't have strong feelings either way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
