On Thu, Oct 5, 2017 at 3:55 PM, Aaron D. Mihalik <[email protected]> wrote: > 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.
I would agree, avoid the forced push. Other than the tagged ones, one can't really make assumptions about the state of commits in branches under active development. > > 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= >> >>> >> >> >>
