Replies: 4 comments 6 replies
-
|
I strongly agree on the need to make a release ASAP. PMD 7 has been in development too long, and even if there is still plenty of things we would love to do, that doesn't take away from all the amazing stuff that's already there, and not currently delivering value to users. For instance, a big portion of reported false positives / negatives on PMD 6 are non-existing on PMD 7 simply because of the more powerful grammar. There are also plenty of open issues because we "haven't backported the fix / feature into PMD 6". Releasing it allows is to clean up and move ahead. I'd try and be aggressive at staking the minimum to get PMD 7 out of the door (ie: no new rules, no further major refactors), focusing on missing rule deprecations (if any), wrapping up existing work, and that pending work we already identified as blockers (ie: #4120). My proposal would be to start out by creating a PMD 7.1.0 milestone, and start moving over to that everything that is non-blocker. The rest, we can split into milestones as suggested by @adangel. |
Beta Was this translation helpful? Give feedback.
-
Yeah, that's the difficult part. I thought for a while, that e.g. the rule deprecations should all be done before PMD 7, but actually - they don't need to. We can easily deprecate rules in PMD 7 and remove them in PMD 8. Maybe your wording with "blockers" helps. I think, what we should make sure is: Whatever is marked as
The milestone 7.1.0 is a good idea, I'll add it to the tasks above. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I think, I'm ready with my proposal: I'd suggest to have 3 release candidates, each focusing on some specific part:
Right now this shows up in PMD 7 Tracking Issue #3898 with 41 remaining tasks. I've moved other issues, that I didn't consider as necessary, into Milestone 7.x and removed them from the project PMD 7. I didn't create a release plan with actual times, as that would be ridiculous given the dedicated time all of us has available... Instead I'd like to work the list from top to bottom (and hopefully not opening a can of worms with more refactoring...). My decisions, which issues are necessary or not for a PMD 7 release, may seem arbitrary - and sometimes they probably are. Please let me know, if you think one task is really necessary (or isn't). And moving the issue to 7.x doesn't mean, it is forbidden to implement this per se for 7.0.0. It just means that I don't believe we have time to do it. If you have time, PRs are welcome. However, try to keep the can of worms closed and try to implement it minimally invasive though... Note, that the Milestone 7.0.0 has more open issues than the new tracking issue. That's because of the rule fixes, that are done on the pmd/7.0.x branch, but not for pmd6. |
Beta Was this translation helpful? Give feedback.
-
Yes, definitely. When we are a bit nearer to the release, we'll close them. Theoretically, github will close them once we merge pmd/7.0.x into master... (but I guess, we should still double check) |
Beta Was this translation helpful? Give feedback.
-
|
I think we need to add a task to get rid of Also, we never said this explicitly, but I'd love that for each RC milestone we actually do a release and announce it publicly… I've been using PMD 7 quite intensively these last couple days and came across multiple bugs and issues (as seen by my Github activity), having more people use it and provide feedback will be critical for the release to be successful. |
Beta Was this translation helpful? Give feedback.
-
I've created #4367 and added it to the list for rc3
Yes, that's the plan. Not sure yet, whether we should mark the release on github as a pre-release or not. But in terms of the release process, the RC3 releases are meant to be "normal" full blown official releases. With release notes. Regarding release notes, I'm not sure yet, whether we should include in rc2 all the changes from rc1 and rc2 or only the rc2 changes - likewise, when we release the final 7.0.0, whether we should repeated the changes from rc1-rc3 or mention only the changes rc3..7.0.0? I'm inclined to have full release notes for 7.0.0 (which means, it duplicates in part rc1-rc3). What we also need to think about is, when we stop merging master->pmd/7.0.x... With @oowekyala we moved already one java cleanup task (#3751) from rc1 to rc3, as with renaming classes we can expect some difficulties in merging. I guess, till rc3 we need to know, what we do. Maybe we can also do this instead: just before the rc1 release, we merge pmd/7.0.x back into master and release PMD7 from master branch... And then it's done. After rc1, PMD7 development would then simply happen on master directly. |
Beta Was this translation helpful? Give feedback.
-
|
My take on these open questions:
I'd say the release notes for PMD 7 (feature wise) should be the same for all, as we want users helping us to know what is in the release / be enticed to trying it out. We will obviously extend the fixed issues / contributions sections as needed. At most, I'd add a "what's new since rc#?" section, but to be honest, it seems it will only be useful for RC2, so maybe it's not worth it.
Is this even a real problem? Do we plan to support PMD 6 after PMD 7? We never did that for PMD 5 (which would face similar issues)… I'd just merge back to master and take it from there for simplicity's sake. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Juan on release notes question. I also don't think we should support PMD 6 with bugfixes after we make PMD 7 our development mainline. Regarding the development branch, I think it makes sense to merge pmd/7.0.x into master some time between RC1 and RC3. IMO, that would ideally be when the RC is "stable enough", which might only mean after RC3 because that RC will rename and move a lot of APIs. At that point we can announce that the 6.x release cycle has ended. We can then release 7.0.0 a month later like our regular schedule, and use that time for bugfixes and doc based on feedback on the RC3. The reason for waiting for a "stable enough" RC is that we want people to use it, possibly to port their rules and such. I don't think this will really happen if we still have a large bunch of pending breaking changes. |
Beta Was this translation helpful? Give feedback.
-
👍
It's right now only a theoretical problem. Let's deal with it only when it becomes a real problem. dev branch: It seems, the simplest way forward would be, to just merge pmd/7.0.x into master after PMD 7.0.0 is released. That means, we release PMD 7.0.0 from the branch (which hopefully works...) and any later version from master. I don't think, we need to do the merge before the rc3 or final release - the important thing is, that we have a rc1 out there, that people can use to update their own tooling. I don't think, they would use our source repo for doing this - at least, I don't clone the repos of my dependencies by default... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
PMD 7 development started a long time back (actually in 2018, see 48d54b0a). The first PR was #1426 back in November 2018. We had many plans and tasks and issues, what we wanted to do. Most notably
There are still many tasks open and many things to improve. We could go on forever and never release PMD 7...
Or we can try to consolidate what we have already for PMD 7 and verify, that it is indeed "ready for release" (whatever this means).
Pro for making a release as soon as possible
Contra to keep on working on PMD 7 (and counter arguments)
The biggest question
So, for me, it seems, that biggest question is: What prevents us from releasing PMD 7 right now?
What is "ready for release"?
Things, that come into my mind are
@DeprecatedUntil700): When do we remove it?Keep in mind, that many things can be done later, e.g. in PMD 7 or PMD 8. Once PMD 7 is out, we can figure out, how to e.g. improve the ruleset schema, etc. We can go on and change one piece at a time.
And once PMD 7 is released, we can immediately work on PMD 8 and so on. Ideally, we won't create a branch anymore, otherwise we run into the same problem again: We don't know, when the branch is "ready" and we don't release it soon. It's better, to release often and smaller steps, than to release never (consider 5 years timespan as never).
The ultimate goal
My ultimate goal is to create a concrete roadmap using release candidates towards a PMD 7 release in 2023 (!, sigh) - finally.
Approach
I'm working on a document in the wiki: https://github.com/pmd/pmd/wiki/PMD-7.0.0-Status
This document has the goal to provide a comprehensive and complete overview of the status of PMD 7.
Here are my steps I'm working on (in that order):
PMD 7, but the other part can be done later
that can be used. But it doesn't need to be perfect (there will always be bugs).
Beta Was this translation helpful? Give feedback.
All reactions