[
https://issues.apache.org/jira/browse/MPMD-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845253#comment-17845253
]
ASF GitHub Bot commented on MPMD-379:
-------------------------------------
adangel commented on PR #144:
URL: https://github.com/apache/maven-pmd-plugin/pull/144#issuecomment-2104232352
> @adangel That merge was a pile of junk. You imported all intermediate work
into master making it impossible to trace down the actual change. Don't do that
again please, always squash and rebase first. Clearly a -1 for the methodology.
I was not aware, that the general rule of thumb for merging PRs is "squash
and rebase". If this is the common
decision around the maven project, then I'd expect this to be clearly
documented, e.g. on https://maven.apache.org/developers/conventions/git.html .
I'm missing there an example on how to merge PRs which consist of more than
one commits. E.g. it says there
"commit it to a branch, fix it up, and merge the branch." instead of "commit
it to a branch, fix it up and squash and rebase this branch onto master/main".
To be honest, I'm not sure if it would have prevented my merge push...
(because I don't think I would have read this doc before pushing).
Following the discussion on
https://github.com/apache/maven-fluido-skin/pull/39#issuecomment-1166243030 -
which is very helpful - it seems
the decision is to try to have a linear history on the master/main branch:
> Simply we require linear commit on master branch - from master perspective
final result is important - we needn't history of work on PR in master.
This decision should be somehow officially be documented to be transparent
for everyone...
For me, as a casual committer, who only pushes once every blue moon and
working mostly on other projects, I would suggest to
- Update the PR Template on GitHub with a section "Before merging... Maven
Project requires a linear history, ... squash+rebase. Either before merge or
whoever merges this. See also
https://maven.apache.org/developers/conventions/git.html";. I think, this would
help to remember this decision.
- Enforce via push/update hook to prevent merge commits pushed to
master/main. GitHub has some options to enforce a linear history. I'm sure, the
infra team can configure something similar on gitbox.apache.org. That would at
least prevent someone like me from simply pushing a merge. Of course, it
wouldn't prevent me from pushing the complete rebased history of a PR (which
is also not desired)...
> Upgrade to use PMD 7.0.0 by default
> -----------------------------------
>
> Key: MPMD-379
> URL: https://issues.apache.org/jira/browse/MPMD-379
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
> Reporter: Andreas Dangel
> Assignee: Andreas Dangel
> Priority: Major
> Fix For: 3.22.0
>
>
> Add support for the new major version of PMD.
> This gives support for analyzing Java 21 code.
> The upgrade from PMD 6 to PMD 7 is a major upgrade, that might impact
> end-users, if they use custom rulesets (see
> [https://maven.apache.org/plugins/maven-pmd-plugin/examples/usingRuleSets.html])
> or if they override the dependencies to upgrade PMD at runtime and currently
> use PMD 6.x (see
> [https://maven.apache.org/plugins/maven-pmd-plugin/examples/upgrading-PMD-at-runtime.html]).
>
> Most likely, end-users have to review their rulesets and migrate them to PMD
> 7. Rules might have been renamed or replaced. See
> [https://docs.pmd-code.org/latest/pmd_release_notes_pmd7.html] and
> [https://docs.pmd-code.org/latest/pmd_userdocs_migrating_to_pmd7.html] .
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
