uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: possible speed-up in releasing the rest of the build artifacts
Date Thu, 15 Jul 2010 20:28:08 GMT


On 7/15/2010 11:50 AM, Marshall Schor wrote:
>  The changes in the build and uimaj SVN nodes needed to depend on the build
> tools update staging release are now merged back into the trunk.
>
> I think I can do all the rest of the build artifacts in one go, even though they
> have parent-pom dependencies - this is because the release plugin handles this
> case :-).

Well, it does only if you build all in an aggregate.
So, I am doing this in 3 more parts instead.  First is parent-pom-docbook.
It is now staged to
https://repository.apache.org/content/repositories/orgapacheuima-008/

Next will be everything else except parent-pom-eclipse-plugins-ibm-notice.

-Marshall
> So, I'll now do a staging release for:
>   parent-pom-docbook
>   parent-pom-distr
>   parent-pom-eclipse-plugins
>   parent-pom-eclipse-plugins-ibm-notice
>   parent-pom-ibm-notice
>   parent-pom-single-project
>
> -Marshall
>
> On 7/15/2010 10:08 AM, Marshall Schor wrote:
>>  OK, Based on feedback, I'll go ahead and attempt to do multiple staging
>> repositories for the various parts, and ask for one vote at the end.
>>
>> I do think that we need to follow protocol and do a release vote, even for these
>> build artifacts, since they go into a central, widely-available distribution
>> mechanism (maven-central), even if they are not our end-user artifacts.
>>
>> During this time, I'll be updating the trunk to depend on versions that are not
>> yet voted on.  To build the trunk during this time, you can use two methods:
>>
>> 1) include -Pstaged-release in the maven command, and update your settings.xml
>> entry for this profile to include the various staging repositories (which I'll
>> include with each successful staging), or,
>>
>> 2) checkout and build the trunk "build" projects, using mvn install.  This
>> should put the release versions into your local repo.
>>
>> -Marshall
>>
>> On 7/13/2010 10:52 AM, Marshall Schor wrote:
>>>  I would like to propose the following, with the intent of speeding up the
>>> release of the build artifacts.
>>>
>>> Background - we're currently releasing these one at a time (or a small group
at
>>> a time) where the things being released only depend on other things already
>>> released.
>>>
>>> For example, if there are three artifacts to be released, A B, and C, C depends
>>> on B, and B depends on A,
>>> we do:
>>>   release A (vote),
>>>   update things to depend on the released version of A,
>>>   release B (vote),
>>>   update things to depend on the released version of B,
>>>   release C (vote)
>>>
>>> What about doing it this way:
>>>
>>> Summary:
>>>   Stage A (release:perform) to NEXUS staging repo "SD-A" (no vote yet)
>>>   Update refs to A to release version of A, in trunk (before release vote)
>>>   Update settings.xml staged-release profile to ref SD-A
>>>
>>>   Stage B (release:perform -Pstaged-release) to NEXUS staging repo "SD-B" (no
>>> vote yet)
>>>   Update refs to B to release version of B, in trunk (before release vote)
>>>   Update settings.xml staged-release profile to ref SD-A, and SD-B
>>>
>>>   Stage C (release:perform -Pstaged-release) to NEXUS staging repo "SD-C" (no
>>> vote yet)
>>>   Update refs to C to release version of C, in trunk (before release vote)
>>>   Update settings.xml staged-release profile to ref SD-A, and SD-B, SD-C
>>>
>>> Call for a release vote on A, B, and C together
>>>  
>>>
>>> More wordy description :-)
>>>
>>> (assume A, B, and C artifacts, with C depending on B, and B depending on A, all
>>> to be released):
>>>
>>> Do the release:perform on A, and close the staging directory (Let's label this
>>> staging directory URL; "SD-A")
>>> Then update in other artifacts to depend on A - release version, (in the trunk)
>>> (even though that release hasn't yet been "voted").  This I think could be
>>> allowed, because the "trunk" is not considered a "release".  The slight issue
>>> here is that if someone checks out the trunk in this state, it won't build,
>>> unless the special instructions to add the staging repository in your
>>> settings.xml file are followed.
>>>
>>> Then do release:perform on B, creating the staging directory "SD-B".  To do
>>> this, the release:perform needs to include the -Pstaged-release profile, so it
>>> can find the version of A it is depending on.
>>>
>>> Then update other artifacts to depend on B - release version, (in the trunk)
>>> (again, even though that hasn't yet been "voted"). Also, update the settings.xml
>>> staged-release profile to include both SD-A and SD-B.
>>>
>>> Then do release:perform on C, creating the staging directory "SD-C", as above,
>>> for B.
>>> Then update other artifacts to depend on C - release version, (in the trunk).
>>> Update the settings.xml staged-release profile to include SD-A, SD-B, and SD-C,
>>> and ask the PMC to vote on all of these together, using all those staged
>>> repositories together.
>>>
>>>
>>> The downside of this, as I see it, is that the trunk version for a while will
be
>>> in a state where it will not build without people using a settings.xml profile
>>> which adds the staging repositories to their repository set.
>>>
>>> It is also possible that it won't work (I haven't tried it) due for example,
to
>>> code which might prevent the release plugin from using NEXUS staging repositories.
>>>
>>> Assuming it would technically work, what do you think about this: is it an "OK"
>>> procedure, to do the release voting for these build artifacts?
>>>
>>> I think it would be OK - because
>>>   the trunk isn't guaranteed to always build,
>>>   the build artifacts are not actually what the UIMA project is "releasing"
>>>     (we are more about releasing UIMA,
>>>      but need to release these build artifacts
>>>      to make the maven build process work well for us)
>>>
>>> It might be possible to release from a branch, but I haven't tried this, and
I
>>> think there may be some assumptions in the maven release plugin (such as when
it
>>> reads the <SCM> elements and generates new ones) that assume the release
is from
>>> the trunk.
>>>
>>> -Marshall
>>>
>>>
>

Mime
View raw message