Hello. Le lun. 14 févr. 2022 à 00:23, GitBox <g...@apache.org> a écrit : > > > nhojpatrick commented on pull request #104: > URL: https://github.com/apache/commons-codec/pull/104#issuecomment-1038472244 > > > @garydgregory i agree it could be considered clutter. If all projects are > kept active current it's never an issue. > From experience I'm coming from working with dead or hibernated projects, > when moving company/job/team/project and having to kick start something > building. It use to work on the cicd server, but someone updated that to a > newer maven version or java version so the project i'm working doesn't work > anymore. So 1st things I now always setup is maven wrapper (takari before it > was merge) and enforcer, so the project itself knows was it was last > configured to build under. >
Thanks for the feedback. It has been my understanding that one purpose of "Commons" (and any other community project) is to gather (human) resources in order to keep the code bases "alive".[1] So IMHO, the top priority should be to extend the maintenance team(s). The shift of focus from the community's still official forum (this ML) to GitHub is aggravating[2][3] the maintenance problem: Most components now rely on less than the 3 required votes for release, and can thus easily become "attic" candidates. Regards, Gilles [1] The concept of "mature" library (often floated around here) has been proven (in light of the JDK evolutions) to be a hindrance rather than the sine qua non of user code stability. [2] Backed by the numbers provided the project's report to the ASF board (where the number of "committers" is utterly misleading wrt its actual effect on maintenance capacity). [3] Despite other advantages (not TBD in this thread) brought by the platform (mainly for itself IMO). --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
