The issue with the merge that master is in a funny state for the 10 new commits. If someone checked out the code at any point within those 10 commits, the POMs would be 3.2.11-SNAPSHOT and the release wouldn't be in the history.
Master is fine (i.e. 3.2.12-SNAPSHOT) after the merge commit, so I think that is okay. I think having the 10 funny commits is better than doing a force push and causing work for people with existing forks of Rya. David: Thanks. I guess I was right before I started questioning myself. :) --Aaron On Thu, Oct 5, 2017 at 7:35 AM Puja Valiyil <[email protected]> wrote: > I agree, there isn't anything wrong imo with a merge commit. How is this > done for other projects? > > Sent from my iPhone > > > On Oct 5, 2017, at 2:55 PM, David Lotts <[email protected]> wrote: > > > > What is wrong with having a merge commit? I believe that will bring in > the > > modified pom.xml files that change to the next snapshot version: > > 3.2.12-SNAPSHOT . These changes do not need to be chronologically > correct. > > > > Here is the quote from our awesome wiki instructions, the bold section is > > what we are discussing: > > https://cwiki.apache.org/confluence/display/RYA/How+To+Release+Rya > > > > ---- > > > > After the release has been approved by IPMC > > > > Release the Jars > > Go to https://repository.apache.org/ and release the staging > > repository > > Copy dev artifacts to release > > Create a rel/ tag in Git > > > > git checkout rya-incubating-3.2.10-rc3 > > > > git tag -a rel/rya-incubating-3.2.10 -m "rya-incubating-3.2.10 > > Release" > > > > git push origin rel/rya-incubating-3.2.10 > > Merge Release branch into Master and Delete Release Branch > > <b> > > > > > > > > > > * git checkout master git merge 3.2.10-RC3 git push > > origin --delete 3.2.10-RC3* > > > > *</b>* > > Update the website > > Send out an announce email > > ---- > > > > david. > > > > On Thu, Oct 5, 2017 at 1:36 PM, Aaron D. Mihalik < > [email protected]> > > wrote: > > > >> Those 10 commit are already in master. > >> > >> If we cherry pick the 2 release commits onto master, then that is wrong. > >> Then it looks like the release contains those 10 new commits. > >> > >> If we do a merge, then we'll have the two release commits in the right > >> spot, then the 10 commits, then a "merge commit". > >> > >> --Aaron > >> > >> On Thu, Oct 5, 2017 at 5:34 AM Smith, Andrew <[email protected]> > >> wrote: > >> > >>> I'd like to avoid a force. Could we cherry-pick those 10 commits over > to > >>> master? > >>> > >>> -----Original Message----- > >>> From: Aaron D. Mihalik [mailto:[email protected]] > >>> Sent: Thursday, October 05, 2017 1:17 PM > >>> To: [email protected] > >>> Subject: Merging Release back into Master? > >>> > >>> Hey devs, > >>> > >>> How are we going to handle merging the release back into master? > master > >>> has moved ahead since David marked the release and now the release > branch > >>> is "2 commits ahead, 10 commits behind master." [1] > >>> > >>> I propose pulling the 10 commits added to master on top of the release > >>> branch and then doing a force push of that onto master. what do you > all > >>> think? > >>> > >>> --Aaron > >>> > >>> > >>> [1] > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github. > >> com_apache_incubator-2Drya_tree_3.2.11-2DRC3&d=DwIBaQ&c= > >> Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=U_RyVeYU_ > >> SBiw95AO0whBC3KHS5T7hkPx7rmMyjITF8&m=jWxjJgDMdB609alFiB_ > >> > tKpRXzhLKdCmeM1o5d2GtOCI&s=XudaZE5HhUvHFqSzPwlwopkmViRx73iFyQ2iP_gOtxE&e= > >>> > >> >
