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 15:50:51 GMT
 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 :-).

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