On Jun 28, 2012, at 2:03 PM, Arvind Prabhakar wrote:
> Hi,
>
> On Fri, Jun 22, 2012 at 6:32 AM, Ralph Goers
> <[email protected]>wrote:
>
>> I was looking at
>> https://cwiki.apache.org/confluence/display/FLUME/How+to+Release and
>> noticed that it doesn't document deploying artifacts to the Apache Nexus
>> repository. In fact, it looks like the 1.1 release was never finished as
>> the artifacts can't be found in Maven Central. This is critical for anyone
>> wanting to extend Flume with their own components so I would ask that this
>> please be added as a step to the release process.
>>
>
> Agreed. Since Mike is the RM for 1.2.0 release, I would request him to
> update this page with the relevant details.
>
>
>>
>> I am curious though why the process doesn't use the Maven Release plugin
>> as it appears the project is set up for it to work. That would remove a
>> number of the manual steps that have to take place.
>>
>
> Although I like the release plugin a lot, there is a concern with respect
> how well it fits with the typical release process. For instance, how would
> you create a release candidate build with the plugin? If you do then it
> will change the version identifiers and also create RC specific tags.
> Further, when a release candidate is approved, you would have to run the
> release plugin again to change the version from RC to release version -
> which requires code changes and new tag creation.
>
> That said, there are work arounds for this such as using the release
> version for the release candidate and then updating the tags as more RCs
> are spun. I am not too sure if that is the right thing to do either.
>
> Any suggestions on getting this going are welcome.
I cheat.
I simply do the release with the real version take. All the artifacts end up
in Nexus, including the distribution zips. If the vote passes I manually
remove the distribution artifacts and push them where Infra wants them. I then
promote the other artifacts off to the production nexus where they find their
way to Maven Central. If the vote fails I just drop the nexus staging
repository, revert all the versions in the poms and delete the release tag from
subversion.
IOW - the only thing that actually says RCn are the emails.
The only way to not violate some "best practice" when doing a release is to not
have release candidates at all and change the version number even if the
release fails. I'm not a fan of that.
>
>
>>
>> Also, I noticed in the parent pom that all the flume artifacts are
>> declared with a specific version. Is there a reason that ${project.version}
>> wasn't used instead? This would save the release manager from ever having
>> to edit them.
>>
>
> I believe that all of these versions are only in the parent pom. Therefore
> a simple find/replace should suffice.
>
Sure. It's just that I''m not sure if the release plugin would change them.
With the variable it doesn't matter. Also, you do need to be careful on your
find & replace as other artifacts might have the same version. I've done that
to myself once or twice.
Ralph
