You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Yusaku Sako (JIRA)" <ji...@apache.org> on 2015/03/31 00:37:55 UTC
[jira] [Updated] (AMBARI-10289) Release work for Apache Ambari
Release 2.0.0 RC3
[ https://issues.apache.org/jira/browse/AMBARI-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yusaku Sako updated AMBARI-10289:
---------------------------------
Description:
Release work for Apache Ambari 2.0.0 RC3 release based on the feedback received during RC2 voting.
>From [~hitesh]
{quote}
The pom.xml in https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=log;h=refs/tags/release-2.0.0-rc2 has a snapshot version.
The source tarball also has 2.0.0-SNAPSHOT. Various bits of code ( views ) also have snapshot versions.
Release contains a DISCLAIMER saying Ambari is still incubating. High time this was fixed.
No CHANGES.txt or release notes in the release artifact?
Release artifacts should ideally be named apache-ambari-*. Should the artifact be named *-src-* too ?
sha file is named “.sha” but actually contains a sha1 sig.
The release manager’s keys are not in the KEYS file.
For future releases, you should really use dist for staging a release. Easier to have track and have history on what is being voted on.
Likewise, the KEYS file should also be available on the download link for users to be able to verify the authenticity of the release.
I remember there being a problem the last time around where the api jars were not deployed to nexus and verified as part of the release process. Have those steps been missed again?
{quote}
was:
Release work for Apache Ambari 2.0.0 RC3 release based on the feedback received during RC2 voting.
The pom.xml in https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=log;h=refs/tags/release-2.0.0-rc2 has a snapshot version.
The source tarball also has 2.0.0-SNAPSHOT. Various bits of code ( views ) also have snapshot versions.
Release contains a DISCLAIMER saying Ambari is still incubating. High time this was fixed.
No CHANGES.txt or release notes in the release artifact?
Release artifacts should ideally be named apache-ambari-*. Should the artifact be named *-src-* too ?
sha file is named “.sha” but actually contains a sha1 sig.
The release manager’s keys are not in the KEYS file.
For future releases, you should really use dist for staging a release. Easier to have track and have history on what is being voted on.
Likewise, the KEYS file should also be available on the download link for users to be able to verify the authenticity of the release.
I remember there being a problem the last time around where the api jars were not deployed to nexus and verified as part of the release process. Have those steps been missed again?
> Release work for Apache Ambari Release 2.0.0 RC3
> ------------------------------------------------
>
> Key: AMBARI-10289
> URL: https://issues.apache.org/jira/browse/AMBARI-10289
> Project: Ambari
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Jayush Luniya
> Assignee: Jayush Luniya
> Priority: Blocker
> Fix For: 2.0.0
>
>
> Release work for Apache Ambari 2.0.0 RC3 release based on the feedback received during RC2 voting.
> From [~hitesh]
> {quote}
> The pom.xml in https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=log;h=refs/tags/release-2.0.0-rc2 has a snapshot version.
> The source tarball also has 2.0.0-SNAPSHOT. Various bits of code ( views ) also have snapshot versions.
> Release contains a DISCLAIMER saying Ambari is still incubating. High time this was fixed.
> No CHANGES.txt or release notes in the release artifact?
> Release artifacts should ideally be named apache-ambari-*. Should the artifact be named *-src-* too ?
> sha file is named “.sha” but actually contains a sha1 sig.
> The release manager’s keys are not in the KEYS file.
> For future releases, you should really use dist for staging a release. Easier to have track and have history on what is being voted on.
> Likewise, the KEYS file should also be available on the download link for users to be able to verify the authenticity of the release.
> I remember there being a problem the last time around where the api jars were not deployed to nexus and verified as part of the release process. Have those steps been missed again?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)