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 >> >> >
