[
https://issues.apache.org/jira/browse/YETUS-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15827407#comment-15827407
]
Ajay Yadava commented on YETUS-474:
-----------------------------------
Sorry for late inputs on this. If I understand correctly, it seems that by
default the build.sh will continue even after the releasedocmaker.py fails with
genuine errors. Do we want to make this the desired default behavior? I
understand the use case when we would want build.sh to proceed even if there
are no issues attached with that version, but given the fact that the primary
use case is to actually build a release candidate, someone would want to run it
on a JIRA version and stopping with an error seems to help discover the issues
early and more intuitive approach for newbies. How about a flag to ignore
releasedocmaker.py errors?
> master build broken
> -------------------
>
> Key: YETUS-474
> URL: https://issues.apache.org/jira/browse/YETUS-474
> Project: Yetus
> Issue Type: Bug
> Components: build
> Affects Versions: 0.5.0
> Reporter: Sean Busbey
> Assignee: Suraj Acharya
> Priority: Blocker
> Fix For: 0.5.0
>
> Attachments: Bump_patch_to_0.99.98.patch,
> Bump_patch_to_0.99.99.patch, YETUS-474-01.patch, YETUS-474-02.patch,
> YETUS-474.patch
>
>
> {code}
> ./build.sh --release
> working on version '0.5.0-SNAPSHOT'
> generating release docs.
> There is no issue which has the specified version: 0.5.0
> mv: rename target/0.5.0/RELEASENOTES.0.5.0.md to target/RELEASENOTES.md: No
> such file or directory
> {code}
> I'm guessing it's the version bump and an edge case in handling RDM.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
