Demand-based release schedule?

[adangel]

PMD is currently using a time-based release schedule (see https://docs.pmd-code.org/latest/pmd_about_release_policies.html).

I would like to change this to a demand-based release schedule.

This has the IMHO the following advantages:

• more flexibility in time management
• actually doing a release, because someone requested it (there is demand), than just doing it because it is time (last Friday in month)

More thoughts/consequences of this change:

• A release might contain/accumulate more changes - and some features/fixes might be delivered later.
• For some features, there are external deadlines, e.g. new Java language releases or new Apex language releases. This would need to be considered.

Practical implementation of this change:

• We create an issue "Release x.y.z"
• This issue is part of the milestone
• This issue is created at the beginning of the new release cycle (aka. as part of the last release)
• This issue is pinned
• People can vote for it - if there are enough votes (e.g. 10 + votes), we can decide on a concrete release date
• People can also veto, e.g. if they want to have a (in their opinion) important bugfix included
• People can (already now) test the pre-release before we actually create the release and provide feedback

What do you think?

[adangel]

Ping @oowekyala @jsotuyod @zbynek @UncleOwen @lukasgraef

[UncleOwen]

I personally like the predictability of the current release schedule. Once your fix is in main, there's a maximum of 5 weeks until it is released. That's why I would slightly prefer the current schedule, but I’d be fine with the new schedule as well.

Is there a particular reason you (as the one doing the release work) bring this up?

[zbynek]

I think one release per month is a good frequency. Obviously maintainers should be allowed to spend Friday evenings doing something else than cutting a release, OTOH it would be nice to have some upper bound on the time between releases to have some predictability.

I'm a bit skeptical about having a fixed number of votes as the release trigger, out of the 2300 closed issues only 6 with more than 10 votes, it's unlikely anyone will vote for a release that's not fixing a critical regression.

[adangel]

The reason I bring this is up is this: My motivation to do a release lately is only: No one else is doing this and somehow we promised to do a monthly release.
Knowing the reason, why I do a release (because someone actually wants it - so there is actual demand), would help a bit.

Actually, I want to contribute to PMD... but I'm mostly stuck with PR reviews and doing releases. So - no time left for anything else. I was hoping a bit, if moving the release out of the way, I can free up a bit of time. But that's maybe not so much. Most time for the release takes waiting for maven central, so I can continue with the release of the downstream projects (note: a release of PMD always entails a release of pmd-eclipse-plugin, updating the PMD version in PMD itself and pmd-examples and maybe some other projects I forgot now).
A little bit more could be automated (like making sure the release notes are always ready for release, verifying that all produced artifacts are available at the various places, triggering downstream updates/releases, ...).

it's unlikely anyone will vote for a release that's not fixing a critical regression

But if this is the case, isn't that a sign that no one really needs this release?

[adangel]

Oh, and some practical issue: I simply can't guarantee that I'm always available for a release - might be on vacation or something else.

[lukasgraef]

a release of PMD always entails a release of pmd-eclipse-plugin

I'm not really familiar with the pmd-eclipse-plugin (or eclipse plugins in general for that matter), but skimming over the last 2 years of releases, there's basically only two types of release relevant changes:

• Bump PMD
• Support some new Eclipse, drop support for some older Eclipse

Would it be possible to decouple the pmd-eclipse-plugin releases from the PMD release itself and only release the plugin on changes regarding Eclipse version support?
Do we need a dedicated pmd-eclipse-plugin release for every PMD release, or can the PMD version just be a configuration option?

Would this be a simplification of the release process we could consider?

[adangel]

Would it be possible to decouple the pmd-eclipse-plugin releases from the PMD release itself and only release the plugin on changes regarding Eclipse version support?
Do we need a dedicated pmd-eclipse-plugin release for every PMD release, or can the PMD version just be a configuration option?

Currently the eclipse plugin embeds PMD. It would need some effort to create a functionality to download/update a PMD version. The plugin won't be ready to use after you have installed it - you would first need to point it to a local folder maybe or let it download PMD.

vscode-apex-pmd does support already a configuration option to point to a local path where PMD is installed. It ships also a PMD version, but it is not always up-to-date.

maven-pmd-plugin references a PMD version through dependencies, which might also not be always up-to-date. But you can override the PMD version.

Would this be a simplification of the release process we could consider?

Maybe - but it increases the complexity in other parts. Especially adding classes from outside into eclipse is a bit tricky due to osgi class loading. But probably doable.

[lukasgraef]

I'm also a fan of the current release schedule.

Basically the points that we're already mentioned summarize my sentiment pretty well:

I personally like the predictability of the current release schedule.

and

it would be nice to have some upper bound on the time between releases to have some predictability.

So what if we were to keep a regular release schedule, and just reduce the frequency of releases (e.g. every 2 or at most every 3 months)?
That way we would still keep the desired predictability, but also reduce the effort spent on releases.

Apart from that: Automating and simplifying the release process is always a worthwhile effort.