Hi folks, I probably missed most of the fun here (overworked) but IMHO it makes sense to update both projects to JDK 8
A related question - someone volunteering as release manager? Having said that I can lend a hand for the code changes :) Thanks in advance Siegfried Goeschl > On 29.03.2021, at 02:38, Matt Sicker <boa...@gmail.com> wrote: > > Calling it technical debt is pretty useful, too, because just like > monetary debt, it can be useful to accumulate some in the short term > for productive reasons, but if you don't pay it off and manage it > properly, the interest payments begin to dominate expenses. Interest > on technical debt comes in the form of what would normally be a five > minute effort taking five months and three separate line managers to > sign off on the budget to have it maybe deployed to production after > the last 20 fires have been sufficiently extinguished. :) > > On Sun, 28 Mar 2021 at 17:09, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> WRT rant: >> We call that "technical debt" and to move the needle on that developers are >> (sometimes or always depending on you company) asked to explain the >> "business value" for spending the time (IOW the money) to do so. At which >> point said developers roll their eyes, pull their remaining hair out, or >> both, before being asked to go another "death march"... >> >> Gary >> >> >> On Sun, Mar 28, 2021, 16:18 Thomas Schapitz <t...@online.de> wrote: >> >>>> If they are still on Java 6 or 7, then updating libraries might not be a >>>> priority. >>>> >>>> Gary >>> >>> >>> I second that. >>> >>> If an organization is still reluctant to upgrade at least to JDK 8, its >>> rather unlikely that the same organization is urgently requiring to update >>> to any latest commons release. >>> >>> And if they do in fact urgently require functionality, that is only >>> available in a commons lib requiring JDK 8, it would be a nice incentive >>> for finally considering an to upgrade at least to JDK 8. >>> >>> To me, Apache, especially commons, does a terrific job guarding BC, but in >>> the end, trying to keep this up for the eternity will overstretch the >>> communities resources, and it is breaking the stride. >>> >>> <RANT>On a more personal note: being 20+ years in the industry, I'm really >>> fed up with organizations wanting me to build the newest, shiniest, >>> fanciest crystal palaces of applications, while at the same time >>> restricting me to use the tools from the stone age to achieve that, just >>> because some oaf up there needs the money to upgrade the gadgets in his >>> super yacht. You know, there is something wrong, when the model of the >>> CEO's car is changing more frequently than the versions of your tools. >>> >>> Basically, an organization showing this behaviour is dumping their >>> leniency as a debt into the community, so complaints about that shouldn't >>> be taken too serious. >>> </RANT> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org