uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: possible speed-up in releasing the rest of the build artifacts
Date Wed, 14 Jul 2010 07:29:25 GMT
As said in the example, I think that having A, B and C staged and the vote
for them together sounds a reasonable and simpler approach to go quicker
towards a stable build process and, as long as people are still able to
build using the modified settings.xml, I agree on the fact that the trunk is
intended to contain also some "work in progress" stuff.
Provided there are no technical issues with the release plugin and the Nexus
staging repos I really think it's a good idea so I am +1.
Have a nice day.
Tommaso

2010/7/13 Eddie Epstein <eaepstein@gmail.com>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message