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 14:08:14 GMT
 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