Heyo, I admit, the first time I stumbled apart major components releasing via CD last year, I was confused by it too, however, the more I read myself into CD, the clearer it became. The "build.hash" scheme is the default CD setup, if plugin authors choose to use a different setup, they can modify it and add version pre- or suffixes. For example, the cloudbees-folder-plugin kept the "6." as version prefix. Releasing via CD doesn't mean you can no longer have a semver-like setup, though many plugins didn't explicitly claim they use semver in the first place.
CD performs an automatic release, if you merged pull requests with interesting labels <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml#L10-L37>. If you pull in breaking changes, you would use the corresponding label and outline the impact of the change to raise awareness. > it is a headache and error-prone experience to bump the versions and read every "changelog". The generated changelogs are - by far - much shorter and quicker to read over, considering every "interesting" PR is a release. I have a bunch of plugins updating frequently which do not aggregate changelogs at all. Looking over commit ranges is much more time consuming than reading a changelog, based on my experience. ~ Alex On Thursday, 31 March 2022 at 04:04:24 UTC+2 [email protected] wrote: > So I have next to nothing to add to this as I don't really do plugin dev > or use the cd flow yet but a few thinks I might have picked up over the > years. > > Afaik Jenkins has never claimed to be semver. Lots of people think plugins > are, but it's probably more often not semver than is semver > > Secondly. For CD I believe the version is based on the labels applied to > PRS that get merged. If it's a major or breaking change label, different > bumping behavior vs like chore. I'm not certain though. > > > On Wed., Mar. 30, 2022, 11:48 a.m. Alex, <[email protected]> wrote: > >> I am a user of both Jenkins CloudBees an OSS version. In the last months, >> the Jenkins plugins version scheme changed for a few plugins and the >> experience for Jenkins maintainers to update these plugin with confidence >> regressed. >> >> With the new CD workflow, the version change to `{digit}.{hash}` >> basically telling us that every new version is a major bump and should be >> treated like a breaking change. With such a vast plugin ecosystem and >> deployment that contains 150+ plugins, it is a headache and error-prone >> experience to bump the versions and read every "changelog". >> >> I am not opposed to the continuous delivery and automatic release of >> every commit, I am a big advocate to that approach in OSS and closed-source >> software, however, I think the new jenkins version number is problematic >> and CD should be implemented with a version number such as SemVer >> https://semver.org/ >> >> I created >> https://github.com/jenkins-infra/jenkins-maven-cd-action/issues/19 for >> the issue, but I think a better place should exist to discuss JEP-229. >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/6c870d41-9754-4e14-81d5-b9ff631fde78n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/6c870d41-9754-4e14-81d5-b9ff631fde78n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9a5128da-0464-4e89-b173-a2391886abe4n%40googlegroups.com.
