On Thursday, December 15, 2022 at 3:42:08 AM UTC-7 Jean-Marc Meessen wrote:
> Hello, > > I am taking care of a library that was produced/updated by a GSoC project: > pipeline-metadata-utils > <https://github.com/jenkins-infra/pipeline-metadata-utils>. It is not a > plugin *per se*. Thus I am in unfamiliar territory. > > Thanks for caring for that library. The Jenkins Docs SIG and the Jenkins Pipeline documentation pages thank you! > I need/want to keep this library up to date as I am concerned that a > major bump is required (ex: dropping Java 8) and that I am overseeing it. I > feel very uncomfortable doing this and would appreciate some eyes on this > to give me some advice. > > That library already requires Java 11. As soon as it depended on Jenkins 2.357 or newer, it required Java 11. > Here are my doubts/questions: > > - The pom.xml uses the jenkins 1.92 parent pom. It is tracked by > dependabot and seems to be the latest. Is this assumption correct? Is > there > a link/relation with the plugin parent pom? > > The Jenkins parent pom releases are documented at https://github.com/jenkinsci/pom/releases . The 1.92 release is the most recent release. Dependabot is keeping that version current. The Jenkins parent pom is used for non-plugin Jenkins components: core, libraries, etc. It defines common dependencies and the Maven build flow including static analysis, enforcer rules, and the release flow. The Jenkins plugin pom releases are documented at https://github.com/jenkinsci/plugin-pom/releases . The 4.53 release is the most recent release. > > - It uses the weekly bom (tracked by dependabot). I guess that this is > OK. Is this assumption correct? What is the added value of using the > weekly > bom instead of the LTS one? > > The pipeline metadata utils library is one of the special cases <https://github.com/jenkinsci/bom/blob/master/README.md#depending-on-bom-weekly> where it makes sense to use the weekly plugin bom. It is used in the Pipeline steps doc generator to create the Pipeline steps documentation for the www.jenkins.io site. The Pipeline steps doc generator loads Jenkins plugins and generates the Pipeline steps documentation from the loaded plugins. That allows it to generate the Pipeline steps documentation for plugins that depend on weekly versions that are newer than the most recent Jenkins LTS. We've had plugins that required a Jenkins weekly version that was newer than the most recent Jenkins LTS release. If the plugin steps doc generator depended on the most recent LTS, it would not have been able to load those plugins. > > - The "base" jenkins version is defined as a dependency and is tracked > by dependabot to follow the weekly release. This is OK and in line with > the > above. Is this assumption correct ? > > Yes, it is intentional that the metatdata utils library depends on a base Jenkins version. It uses Jenkins and provides a custom plugin manager implementation that loads plugins in order to extract their Pipeline documentation. > > - The Jenkinsfile defines, via the "tool" command, JDK11 as the build > environment. This probably implies only Linux which would be OK as the > tool using this library is running only on the Jenkins (linux) > infrastructure. Should this be updated to JDK17? > > The Jenkinsfile could be extended to also build with Java 17 as a way to ensure that it will be ready for the eventual time when Jenkins requires Java 17. I don't expect that for at least a year, but it would not be harmful to be checking that the code also compiles and passes all its tests with Java 17. I think it is optional, but not harmful. > > - I guess that all these dependencies live correctly in symbiosis. Or > am I missing something? > > As far as I can tell, the dependencies live correctly in symbiosis. > > - What would be the recommended release cadence (not triggered by new > features or bug fixes)? Just leave it like that or should I release it, > say > every 6 months, to be sure that old (faulty/unsecure?) dependencies are > not > pulled into the instance. > > That's an interesting question. The Pipeline steps doc generator depends on the most recent Jenkins weekly release and builds itself from source each time it generates pipeline step documentation. Since it depends on the most recent weekly release, that is what is used when it runs. The pipeline steps doc generator uses the Pipeline metadata utils library and the metadata utils library dependency on an older Jenkins weekly release is generally not harmful (at least as far as I can tell). As a hunch, I think that we would be good if the pipeline metadata utils library released a new version at least once a quarter, just to avoid the risk that the Pipeline steps doc generator dependency on the most recent weekly does not get too distant from the dependency inside the pipeline metadata utils library. The last release of pipeline metadata utils was in July. We haven't seen an issue with it yet, but a quarterly update seems reasonable to narrow the distance between the library and its consumer. > I think all is good and correctly maintained. Just would like to have a > confirmation of that as well as improvement suggestions. > > /- Jmm > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ad93ca21-f3da-4702-ae8e-28696da2beedn%40googlegroups.com.
