You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2010/10/31 20:52:22 UTC
starting to try release of uimaj sdk
The first step is to release to the staging repo the build tools. I won't call
for a vote, though until I have also a successfully built uimaj candidate :-).
If you see a bunch of release commits for the build tooling etc., that's what's
going on. If things need changing, I'll probably roll-back the release and try
again...
-Marshall
Re: starting to try release of uimaj sdk
Posted by Marshall Schor <ms...@schor.com>.
After more thought and a bit of discussion on release-discuss, I'm going with a
much simpler process, but one which requires that the release manager take an
extra step after the vote passes.
The process will work like this:
Assemblies will be "attached" - so that they will be signed by the gpg plugin,
and have checksums added when they are uploaded to the Nexus staging repository,
during a release:perform.
For testing purposes, developers will find the assemblies in the Nexus staging
repo, under the xxx-distr projects, as attached artifacts, and can download them
from there for testing. I think this use of Apache infrastructure resources is
OK, since the alternative, if we didn't upload them to the Nexus staging repo,
would have been to upload them to some other shared Apache infrastructure spot
(previously, we've used people.a.o/~user/... ). So we're not taking up any more
room.
Once the release passes the vote, before pushing the "release" button on Nexus,
the release manager needs to
1) copy the assemblies from there to the Apache mirrored distribution spot.
2) delete the assemblies from the staging repo, so they won't go up to Maven
Central.
(Step 2 would be new).
I got a response on the release-discuss mailing list, saying another project is
using this method (although they occasionally forget to delete the assemblies...).
This process requires no special Maven configuration - so it must be a Maven
best practice :-) .
-Marshall Schor
On 11/5/2010 7:40 AM, Marshall Schor wrote:
> Hi Tommaso,
>
> I think it's good to use Nexus for stuff that we want to end up going to Maven
> Central. This includes all our individual Jars. And this is now setup and what
> happens when mvn release:perform is done.
>
> However, Maven Central seems *not appropriate* for our big source releases and
> binary releases, which are quite large (> 16 MB each (lots of docs :-) ), and
> which we want the Apache Mirroring system to be used for downloading and
> distribution.
>
> I asked about this on the Maven user's list and got an interesting answer.
> Someone figured out how to do this for their project. It's quite tricky, but I
> can see how it works. It's so tricky, though, that I'm looking around for a
> better answer; to that end I've posted to the "release-discuss" mailing list at
> Apache, and asked others to describe how they "solve" this problem.
>
> Here are pointers to these other mail threads:
>
> on release-discuss: http://markmail.org/message/qh2xm7crjypf23xn
>
> on maven-users: http://markmail.org/message/3lg5xhtsv3bwhpzp
>
> -Marshall
>
> On 11/5/2010 4:34 AM, Tommaso Teofili wrote:
>> Hi Marshall,
>> maybe issuing UIMA on Nexus would help us with that [1].
>> I know some projects use it to stage their RCs.
>> There is a Jira wish for that at [2] (it deals with Hudson too).
>> What do you think?
>> Tommaso
>>
>> [1] : http://wiki.apache.org/portals/FrontPage/HowtoUseNexusForRelease
>> [2] : https://issues.apache.org/jira/browse/UIMA-1717
>>
>> 2010/11/4 Marshall Schor <ms...@schor.com>
>>
>>> Because of issues found, I'm resetting the version of uimaj in trunk back
>>> from
>>> 2.3.2-SNAPSHOT to 2.3.1-SNAPSHOT, and will respin RC2 shortly.
>>>
>>> I'll also redo the build tools, similarly.
>>>
>>> I'm not sure what the best "process" is, but I don't want to keep
>>> incrementing
>>> the version for every release candidate. Please feel free to suggests
>>> better
>>> "process" :-)
>>>
>>> -Marshall
>>>
>>> On 10/31/2010 3:52 PM, Marshall Schor wrote:
>>>> The first step is to release to the staging repo the build tools. I
>>> won't call
>>>> for a vote, though until I have also a successfully built uimaj candidate
>>> :-).
>>>> If you see a bunch of release commits for the build tooling etc., that's
>>> what's
>>>> going on. If things need changing, I'll probably roll-back the release
>>> and try
>>>> again...
>>>>
>>>> -Marshall
>>>>
>>>>
>
Re: starting to try release of uimaj sdk
Posted by Marshall Schor <ms...@schor.com>.
Hi Tommaso,
I think it's good to use Nexus for stuff that we want to end up going to Maven
Central. This includes all our individual Jars. And this is now setup and what
happens when mvn release:perform is done.
However, Maven Central seems *not appropriate* for our big source releases and
binary releases, which are quite large (> 16 MB each (lots of docs :-) ), and
which we want the Apache Mirroring system to be used for downloading and
distribution.
I asked about this on the Maven user's list and got an interesting answer.
Someone figured out how to do this for their project. It's quite tricky, but I
can see how it works. It's so tricky, though, that I'm looking around for a
better answer; to that end I've posted to the "release-discuss" mailing list at
Apache, and asked others to describe how they "solve" this problem.
Here are pointers to these other mail threads:
on release-discuss: http://markmail.org/message/qh2xm7crjypf23xn
on maven-users: http://markmail.org/message/3lg5xhtsv3bwhpzp
-Marshall
On 11/5/2010 4:34 AM, Tommaso Teofili wrote:
> Hi Marshall,
> maybe issuing UIMA on Nexus would help us with that [1].
> I know some projects use it to stage their RCs.
> There is a Jira wish for that at [2] (it deals with Hudson too).
> What do you think?
> Tommaso
>
> [1] : http://wiki.apache.org/portals/FrontPage/HowtoUseNexusForRelease
> [2] : https://issues.apache.org/jira/browse/UIMA-1717
>
> 2010/11/4 Marshall Schor <ms...@schor.com>
>
>> Because of issues found, I'm resetting the version of uimaj in trunk back
>> from
>> 2.3.2-SNAPSHOT to 2.3.1-SNAPSHOT, and will respin RC2 shortly.
>>
>> I'll also redo the build tools, similarly.
>>
>> I'm not sure what the best "process" is, but I don't want to keep
>> incrementing
>> the version for every release candidate. Please feel free to suggests
>> better
>> "process" :-)
>>
>> -Marshall
>>
>> On 10/31/2010 3:52 PM, Marshall Schor wrote:
>>> The first step is to release to the staging repo the build tools. I
>> won't call
>>> for a vote, though until I have also a successfully built uimaj candidate
>> :-).
>>> If you see a bunch of release commits for the build tooling etc., that's
>> what's
>>> going on. If things need changing, I'll probably roll-back the release
>> and try
>>> again...
>>>
>>> -Marshall
>>>
>>>
Re: starting to try release of uimaj sdk
Posted by Tommaso Teofili <to...@gmail.com>.
Hi Marshall,
maybe issuing UIMA on Nexus would help us with that [1].
I know some projects use it to stage their RCs.
There is a Jira wish for that at [2] (it deals with Hudson too).
What do you think?
Tommaso
[1] : http://wiki.apache.org/portals/FrontPage/HowtoUseNexusForRelease
[2] : https://issues.apache.org/jira/browse/UIMA-1717
2010/11/4 Marshall Schor <ms...@schor.com>
> Because of issues found, I'm resetting the version of uimaj in trunk back
> from
> 2.3.2-SNAPSHOT to 2.3.1-SNAPSHOT, and will respin RC2 shortly.
>
> I'll also redo the build tools, similarly.
>
> I'm not sure what the best "process" is, but I don't want to keep
> incrementing
> the version for every release candidate. Please feel free to suggests
> better
> "process" :-)
>
> -Marshall
>
> On 10/31/2010 3:52 PM, Marshall Schor wrote:
> > The first step is to release to the staging repo the build tools. I
> won't call
> > for a vote, though until I have also a successfully built uimaj candidate
> :-).
> >
> > If you see a bunch of release commits for the build tooling etc., that's
> what's
> > going on. If things need changing, I'll probably roll-back the release
> and try
> > again...
> >
> > -Marshall
> >
> >
>
Re: starting to try release of uimaj sdk
Posted by Marshall Schor <ms...@schor.com>.
Because of issues found, I'm resetting the version of uimaj in trunk back from
2.3.2-SNAPSHOT to 2.3.1-SNAPSHOT, and will respin RC2 shortly.
I'll also redo the build tools, similarly.
I'm not sure what the best "process" is, but I don't want to keep incrementing
the version for every release candidate. Please feel free to suggests better
"process" :-)
-Marshall
On 10/31/2010 3:52 PM, Marshall Schor wrote:
> The first step is to release to the staging repo the build tools. I won't call
> for a vote, though until I have also a successfully built uimaj candidate :-).
>
> If you see a bunch of release commits for the build tooling etc., that's what's
> going on. If things need changing, I'll probably roll-back the release and try
> again...
>
> -Marshall
>
>
Re: starting to try release of uimaj sdk
Posted by Tommaso Teofili <to...@gmail.com>.
Thanks Marshall, I your process proposal is good.
Tommaso
2010/11/5 Marshall Schor <ms...@schor.com>
> starting rc2 for build tooling and uimaj :-)
>
> -Marshall
>
> On 10/31/2010 3:52 PM, Marshall Schor wrote:
> > The first step is to release to the staging repo the build tools. I
> won't call
> > for a vote, though until I have also a successfully built uimaj candidate
> :-).
> >
> > If you see a bunch of release commits for the build tooling etc., that's
> what's
> > going on. If things need changing, I'll probably roll-back the release
> and try
> > again...
> >
> > -Marshall
> >
> >
>
Re: starting to try release of uimaj sdk
Posted by Marshall Schor <ms...@schor.com>.
starting rc2 for build tooling and uimaj :-)
-Marshall
On 10/31/2010 3:52 PM, Marshall Schor wrote:
> The first step is to release to the staging repo the build tools. I won't call
> for a vote, though until I have also a successfully built uimaj candidate :-).
>
> If you see a bunch of release commits for the build tooling etc., that's what's
> going on. If things need changing, I'll probably roll-back the release and try
> again...
>
> -Marshall
>
>