uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Epstein <eaepst...@gmail.com>
Subject Re: possible speed-up in releasing the rest of the build artifacts
Date Tue, 13 Jul 2010 20:44:19 GMT
What seems to be going on to me is that you are working on a new build process
that will ultimately simplify building UIMA, and that requires some
number of "build
artifacts" to be populated in NEXUS staging repositories. I do not see the build
artifacts as being something requiring a vote. This activity is more
in the line of
advising developers you are moving in a particular direction and,
given no objections,
doing it.

Ideally you could have done all this work without changing the build process for
others until all was ready, but this sounds like Monday morning commentary on
Sunday's game.

Anyway, I'm +1 for putting out build artifacts without a vote.

Eddie

On Tue, Jul 13, 2010 at 10:52 AM, Marshall Schor <msa@schor.com> 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