[
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17855246#comment-17855246
]
Konrad Windszus commented on JCRVLT-754:
----------------------------------------
bq. For the basenames, can we switch it for filevault maintenance releases as
well,
Yes, although it is unlikely to happen. Therefore supporting both ZIP filename
formats is IMHO too much effort
I am not sure about the intent of of the additional check of the SHA1 given as
parameter. There is already a check if the checksums are correctly calculated
for the to-be release source ZIP. What exactly do we want to verify here? Check
if someone replaced the source ZIP and the checksums in the SVN repo as well
as modified the Git tag after the vote has been sent out? Not sure this is
worth checking at all. I would rather tend to make this additional SHA CLI
argument for {{check-release.sh}} optional and leave it out for FileVault. WDYT
[~reschke]?
> check-release does not work for filevault anymore
> -------------------------------------------------
>
> Key: JCRVLT-754
> URL: https://issues.apache.org/jira/browse/JCRVLT-754
> Project: Jackrabbit FileVault
> Issue Type: Task
> Reporter: Julian Reschke
> Assignee: Konrad Windszus
> Priority: Major
> Fix For: 3.7.4
>
>
> Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated
> anymore; however, this is what is put into the generated vote template.
> The proper fix likely would be to put the SHA512 checksum into the vote
> template.
> Furthermore, the basename of the source artefact changed from"src" to
> "source-release". This needs to be adjusted in the check script.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
