The release versions of parent-pom-annotator parent-pom-eclipse-plugins parent-pom-ibm-notice parent-pom-single-project
have been staged to https://repository.apache.org/content/repositories/orgapacheuima-010/ One more to go: parent-pom-eclipse-plugins-ibm-notice -Marshall On 7/15/2010 4:28 PM, Marshall Schor wrote: > > 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 >>>> >>>> >
