nknize commented on PR #37: URL: https://github.com/apache/sis/pull/37#issuecomment-1668627126
This is a great explanation. My personal opinion and preference is to have each commit as a separate PR just to make it easier to follow and track the changes. Especially as time passes it's kind of nice to go back and see smaller PRs. I think if the build doesn't pass it's okay? Especially since main is an unstable snapshot anyway? Just my $0.02. - Nick On Mon, Aug 7, 2023, 4:48 PM Martin Desruisseaux ***@***.***> wrote: > We could split in separated merge requests, but the migration from Maven > to Gradle is very different depending on whether it is done before or after > restructuring from *Package Hierarchy* to *Module Source Hierarchy*. If > we migrate to Gradle before, it would be like doing the migration twice > given the amount of changes needed in Gradle scripts and plugins (buildSrc) > after restructuring to Module Source Hierarchy. > > Currently the separation is done in commits as below. Those commits are in > dependency order, and each of them could be taken as a merge request on its > own (git "squash" and "rebase" were done extensively). > > 1. Cleaning work > - Remove the NetBeans Ant project > - Remove test JAR files. Consequently tests cannot be executed > anymore (temporarily) > 2. Partial JPMS > - Add module-info.java. Project can still be executed with Maven, > but not tested. > 3. Restructuring from Package Hierarchy to Module Source Hierarchy > - Remove all Maven project files (because they don't work at all > with Module Source Hierarchy) > - Move all Java source files to their new location with no change > in any code. > - Post move cleanup (code changes caused by restructuring are > separated in this commit). > 4. Migrage from Maven to Gradle. > - Add Gradle build scripts, adapted to Module Source Hierarchy. > - Documentation updates (mostly editions in Javadoc). > > As seen above, the commits are in 4 groups which could be separated in 4 > merge requests. The reason why they are proposed in a single merge request > is because the project is temporarily unbuildable and/or untestable during > some intermediate steps. The project is back to buildable and testable > state only after the last commit (ignoring the documentation updates). > > So would it still be better to split in 2 or more merge requests anyway? > > — > Reply to this email directly, view it on GitHub > <https://github.com/apache/sis/pull/37#issuecomment-1668622209>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGKV244FM3ZFHGL2ABHUGTXUFPEXANCNFSM6AAAAAA3HEYPJ4> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@sis.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
