[
https://issues.apache.org/jira/browse/OAK-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341673#comment-15341673
]
Francesco Mari edited comment on OAK-4487 at 6/21/16 2:16 PM:
--------------------------------------------------------------
bq. I think if you want to individually release the oak-segment-tar bundle,
you'll have to create the dedicated apache-release profile. It will share most
of the things with other project but it will be slightly different as it cares
on only 1 bundle.
The {{apache-release}} profile inherited from the Apache parent POM should
already take care of every required release configuration. The configuration in
our own {{apache-release}} profile doesn't add any inherent value to the single
module use case, if not for the generation of the text for the voting email.
bq. plus the current release actually creates a tag in svn as jackrabbit-oak
and then the script we run for checking the release, checks the sources of the
zip file against the tag.
https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh.
The tag would be created for release of oak-segment-tar as well: this is taken
care of by the Maven Release Plugin. As for the other steps in
{{check-release.sh}}, are they really necessary given that the release
artifacts are cryptographically signed?
According to [this
section|http://www.apache.org/dev/release-signing.html#check-integrity] of the
Signing Releases guide, checking the source of the zip against the tag doesn't
guarantee authentication and non-repudiation. On [another
section|http://www.apache.org/dev/release-signing.html#verifying-signature] of
the same guide, it's explained that the desired level of authentication and
non-repudiation can be reached by verifying the signature of the released
artifacts. This is exactly what {{check_staged_release.sh}} does.
bq. An easier way would be to simply allow oak-segment-tar to be deployed along
with the normal oak release. That would simplify things.
This is a false economy, in my opinion. At least for this module, we agreed to
try out an approach where release numbers would actually have a meaning. The
problem is that for this to work, as you can see, the rest of the build
infrastructure needs some slight adaptations.
was (Author: frm):
bq. I think if you want to individually release the oak-segment-tar bundle,
you'll have to create the dedicated apache-release profile. It will share most
of the things with other project but it will be slightly different as it cares
on only 1 bundle.
The {{apache-release}} profile inherited from the Apache parent POM should
already take care of every required release configuration. The configuration in
our own {{apache-release}} profile doesn't add any inherent value to the single
module use case, if not for the generation of the text for the voting email.
bq. plus the current release actually creates a tag in svn as jackrabbit-oak
and then the script we run for checking the release, checks the sources of the
zip file against the tag.
https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh.
The tag would be created for release of oak-segment-tar as well: this is taken
care of by the Maven Release Plugin. As for the other steps in
{{check-release.sh}}, are they really necessary given that the release
artifacts are signed and checksummed?
bq. An easier way would be to simply allow oak-segment-tar to be deployed along
with the normal oak release. That would simplify things.
This is a false economy, in my opinion. At least for this module, we agreed to
try out an approach where release numbers would actually have a meaning. The
problem is that for this to work, as you can see, the rest of the build
infrastructure needs some slight adaptations.
> Move the apache-release profile in oak-parent
> ---------------------------------------------
>
> Key: OAK-4487
> URL: https://issues.apache.org/jira/browse/OAK-4487
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
> Reporter: Francesco Mari
> Assignee: Francesco Mari
> Fix For: 1.6
>
>
> The {{apache-release}} profile in the root POM defines some required steps to
> build release artifacts in Oak. This profile should be moved to the POM in
> {{oak-parent}} so that these steps can be shared between different modules.
> As a concrete example, oak-segment-tar should be able to reuse these steps to
> be compliant with our release process. For further details, see OAK-4446.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
