[ 
https://issues.apache.org/jira/browse/YETUS-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234539#comment-16234539
 ] 

Allen Wittenauer edited comment on YETUS-568 at 11/1/17 6:36 PM:
-----------------------------------------------------------------

Given the feedback, -00 is probably better. Deleting -01.


was (Author: aw):
Deleting -01.

> break apart versioning of files and directories
> -----------------------------------------------
>
>                 Key: YETUS-568
>                 URL: https://issues.apache.org/jira/browse/YETUS-568
>             Project: Yetus
>          Issue Type: Improvement
>          Components: Release Doc Maker
>            Reporter: Allen Wittenauer
>            Assignee: Allen Wittenauer
>            Priority: Major
>         Attachments: YETUS-568.00.patch
>
>
> Currently, releasedocmaker always generates a version directory wherever it 
> is told to write it's output:
> {code}
> rdm -p yetus -v 0.6.0   ->   0.6.0/CHANGES.0.6.0.md
>                                            0.6.0/RELEASENOTES.0.6.0.md
> rdm -o foo -p yetus -v 0.6.0   ->   foo/0.6.0/CHANGES.0.6.0.md
>                                                      
> foo/0.6.0/RELEASENOTES.0.6.0.md
> {code}
>  
> In some situations, this is really less than ideal, especially given that the 
> files also have the version stuck in them. (In fact, the current rdm output 
> is making life difficult for Yetus' own release process.)
> We need to rethink this a bit.  Some ideas for improvement:
> * Add a flag (--fileversions?)  that add the version to the filenames, e.g., 
> CHANGES.MD to CHANGES.0.6.0.md
> * Add a flag (--dirversions?) that creates the version directory.  e..g., -O 
> foo --dirversions would write in foo/0.6.0 as it does today. 
> While we are breaking rdm, it may be worthwhile to change from CHANGES to 
> CHANGELOG, which will make a lot of other software that looks specifically 
> for CHANGELOG files happy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to