On 7/15/2010 11:50 AM, Marshall Schor wrote: > 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 :-).
Well, it does only if you build all in an aggregate. So, I am doing this in 3 more parts instead. First is parent-pom-docbook. It is now staged to https://repository.apache.org/content/repositories/orgapacheuima-008/ Next will be everything else except parent-pom-eclipse-plugins-ibm-notice. -Marshall > 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 >>> >>> >
