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 21:07:00 GMT
 The release versions of

  parent-pom-annotator
  parent-pom-eclipse-plugins
  parent-pom-ibm-notice
  parent-pom-single-project

have been staged to
https://repository.apache.org/content/repositories/orgapacheuima-010/

One more to go: parent-pom-eclipse-plugins-ibm-notice

-Marshall

On 7/15/2010 4:28 PM, Marshall Schor wrote:
>
> 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