Supported versions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Supported versions

Juan Martín Sotuyo Dodero
I write this email to start a discussion on which versions we would keep on supporting in the future.

With support for PMD 5.3 retired, all supported PMD versions require Java 7 (except for Apex which requires Java 8).

Given that the 2 currently supported versions and the next minor release (5.6.0) all have the same requirements, I wonder on the actual value of keeping all 3 versions updated.

Doing so adds overhead and merge conflicts for us when proposing changes / merging PRs, and I see no value for users with no reasons to keep behind the latest release, specially considering most will just use whatever version Gradle / Maven ships by default.

Moreover, this multi-version support introduces noise when announcing a new minor version. For instance, PMD 5.6.0's changelog states, among it's major new features, a new security ruleset for Apex... but that ruleset was released in PMD 5.5.3, so it's not actually new to those users that updated... This scenario has repeated over and over in the past.

I therefore propose that, once we release 5.6.0, we move to a simpler schema. We drop support for PMD 5.4 and 5.5. We just start working on PMD 5.7.0, and a month later, hopefully that's the version we release, and we move on to 5.8.0. We would only use patch versions for actual patches to big regressions on the latest release (ie: we introduced a NPE during analysis), and such patch versions are released immediately after the issue is fixed rather than on a fixed schedule.

This means we are also adopting a more semantic version system. We no longer introduce new rules / features / rule changes to patch versions, but keep that for minor releases.

Just having to support the latest version means a simpler workflow for us (we may got as far as actually merging PRs from Github if we dared!), and helps push everyone towards a single latest version (which in turn means we get more and better issue reports).

I'd love to hear your feedback! Can you think of any valid reason for someone using 5.4.x not updating to 5.6.0?

Regards

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Pmd-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmd-devel
Reply | Threaded
Open this post in threaded view
|

Re: Supported versions

Andreas Dangel-2

Yes, I agree - the release notes of 5.6.0 are quite big now...

Reasons why not updating to 5.6.0: the new version might not be a simple drop-in replacement (as in overriding the maven dependencies). It's usually not a big deal to adjust e.g. the maven-pmd-plugin, if we changed some API. But it's nothing, that an end-user would do. Since I also have commit permissions for this maven-pmd-plugin, I don't see a problem there, to push for 5.6.0.

This means we are also adopting a more semantic version system. We no longer introduce new rules / features / rule changes to patch versions, but keep that for minor releases.
+1

About merging: I think, it would be ideal, to have each commit only once in the repo. Currently, we rebase the PRs, merge them and also merge to original PR - so that it appears as "merged" rather than "closed". This creates also noise in the commit history...

Being strict about this versioning, would mean: If a bug fix requires some improvement in the codebase (e.g. Symbol table, type resolution, ...) we should maybe just fix this bug on master. If we release from master anyway 1 month later, this should not be a problem. Well, thinking about it - it's maybe not a good idea, to make such a general rule - it depends on the bug...

Other question: How do you imagine, the bugfixes are done? Would we fix them first on master and then maybe cherry-pick to the relevant branch/branches? Cherry-Picking means, the commit is duplicated again (same content, but two commits). But given that the maintenance branches are very short-lived, I would be Ok with that. The alternative is using branches for bugfixes and merging the bugfix into master + the other branches.

In any case, the master branch would be main focus point, which is good :)


By the way - the automatic releases via travis are hopefully in place and working by now. I used it for the last releases, it mostly worked. I did not see yet, that the release notes were successfully uploaded to github releases, but all the other steps are fully automatic now. From this side, there now no reason anymore, to wait for the next bugfix release...



Cheers,

Andreas




Am 03.03.2017 um 20:30 schrieb Juan Martín Sotuyo Dodero:
I write this email to start a discussion on which versions we would keep on supporting in the future.

With support for PMD 5.3 retired, all supported PMD versions require Java 7 (except for Apex which requires Java 8).

Given that the 2 currently supported versions and the next minor release (5.6.0) all have the same requirements, I wonder on the actual value of keeping all 3 versions updated.

Doing so adds overhead and merge conflicts for us when proposing changes / merging PRs, and I see no value for users with no reasons to keep behind the latest release, specially considering most will just use whatever version Gradle / Maven ships by default.

Moreover, this multi-version support introduces noise when announcing a new minor version. For instance, PMD 5.6.0's changelog states, among it's major new features, a new security ruleset for Apex... but that ruleset was released in PMD 5.5.3, so it's not actually new to those users that updated... This scenario has repeated over and over in the past.

I therefore propose that, once we release 5.6.0, we move to a simpler schema. We drop support for PMD 5.4 and 5.5. We just start working on PMD 5.7.0, and a month later, hopefully that's the version we release, and we move on to 5.8.0. We would only use patch versions for actual patches to big regressions on the latest release (ie: we introduced a NPE during analysis), and such patch versions are released immediately after the issue is fixed rather than on a fixed schedule.

This means we are also adopting a more semantic version system. We no longer introduce new rules / features / rule changes to patch versions, but keep that for minor releases.

Just having to support the latest version means a simpler workflow for us (we may got as far as actually merging PRs from Github if we dared!), and helps push everyone towards a single latest version (which in turn means we get more and better issue reports).

I'd love to hear your feedback! Can you think of any valid reason for someone using 5.4.x not updating to 5.6.0?

Regards


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Pmd-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmd-devel


-- 
Andreas Dangel
https://github.com/adangel
skype: andreas_dangel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Pmd-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmd-devel
Reply | Threaded
Open this post in threaded view
|

Re: Supported versions

Juan Martín Sotuyo Dodero

Sorry for the delay.

I imagine a scenario where patch versions are uncommon, only reserved to hot fix botched releases. The only case in the last year or so I can recall where we could have considered introducing a patch version was with PMD 5.5.3 introducing a NPE with -ignore-identifiers and a ClassCastException in UnnecessaryLocalBeforeReturn.

On such scenarios, once the issue is brought to our attention, we prepare a support branch (we could continue using pmd/x.y.z branch names), we add a failing test scenario for the crash, we fix it, and release it.

The branch is then merged back into master (although not deleted), this merge will produce merge conflicts for version config on poms, which we will resolve by always keeping what was in master (next minor version). This way the hot fix is back in master for future releases.


On Sat, Mar 4, 2017 at 3:13 PM, Andreas Dangel <[hidden email]> wrote:

Yes, I agree - the release notes of 5.6.0 are quite big now...

Reasons why not updating to 5.6.0: the new version might not be a simple drop-in replacement (as in overriding the maven dependencies). It's usually not a big deal to adjust e.g. the maven-pmd-plugin, if we changed some API. But it's nothing, that an end-user would do. Since I also have commit permissions for this maven-pmd-plugin, I don't see a problem there, to push for 5.6.0.

This means we are also adopting a more semantic version system. We no longer introduce new rules / features / rule changes to patch versions, but keep that for minor releases.
+1

About merging: I think, it would be ideal, to have each commit only once in the repo. Currently, we rebase the PRs, merge them and also merge to original PR - so that it appears as "merged" rather than "closed". This creates also noise in the commit history...

Being strict about this versioning, would mean: If a bug fix requires some improvement in the codebase (e.g. Symbol table, type resolution, ...) we should maybe just fix this bug on master. If we release from master anyway 1 month later, this should not be a problem. Well, thinking about it - it's maybe not a good idea, to make such a general rule - it depends on the bug...

Other question: How do you imagine, the bugfixes are done? Would we fix them first on master and then maybe cherry-pick to the relevant branch/branches? Cherry-Picking means, the commit is duplicated again (same content, but two commits). But given that the maintenance branches are very short-lived, I would be Ok with that. The alternative is using branches for bugfixes and merging the bugfix into master + the other branches.

In any case, the master branch would be main focus point, which is good :)


By the way - the automatic releases via travis are hopefully in place and working by now. I used it for the last releases, it mostly worked. I did not see yet, that the release notes were successfully uploaded to github releases, but all the other steps are fully automatic now. From this side, there now no reason anymore, to wait for the next bugfix release...



Cheers,

Andreas




Am 03.03.2017 um 20:30 schrieb Juan Martín Sotuyo Dodero:
I write this email to start a discussion on which versions we would keep on supporting in the future.

With support for PMD 5.3 retired, all supported PMD versions require Java 7 (except for Apex which requires Java 8).

Given that the 2 currently supported versions and the next minor release (5.6.0) all have the same requirements, I wonder on the actual value of keeping all 3 versions updated.

Doing so adds overhead and merge conflicts for us when proposing changes / merging PRs, and I see no value for users with no reasons to keep behind the latest release, specially considering most will just use whatever version Gradle / Maven ships by default.

Moreover, this multi-version support introduces noise when announcing a new minor version. For instance, PMD 5.6.0's changelog states, among it's major new features, a new security ruleset for Apex... but that ruleset was released in PMD 5.5.3, so it's not actually new to those users that updated... This scenario has repeated over and over in the past.

I therefore propose that, once we release 5.6.0, we move to a simpler schema. We drop support for PMD 5.4 and 5.5. We just start working on PMD 5.7.0, and a month later, hopefully that's the version we release, and we move on to 5.8.0. We would only use patch versions for actual patches to big regressions on the latest release (ie: we introduced a NPE during analysis), and such patch versions are released immediately after the issue is fixed rather than on a fixed schedule.

This means we are also adopting a more semantic version system. We no longer introduce new rules / features / rule changes to patch versions, but keep that for minor releases.

Just having to support the latest version means a simpler workflow for us (we may got as far as actually merging PRs from Github if we dared!), and helps push everyone towards a single latest version (which in turn means we get more and better issue reports).

I'd love to hear your feedback! Can you think of any valid reason for someone using 5.4.x not updating to 5.6.0?

Regards


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Pmd-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmd-devel


-- 
Andreas Dangel
https://github.com/adangel
skype: andreas_dangel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Pmd-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmd-devel



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Pmd-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmd-devel