Current version patterns in used based only on a subset of plugins I have in my instances are 1.0 1.0.0 1.0.0-0 2.v1234abcdef 1.2.v1234abcdef 1.0.2.v1234abcdef 1.0.0-2.v1234abcdef
I think the knew CD workflow with the *documented version scheme and patterns*, either the default or the manual ones, is just causing more discrepancies in the plugin ecosystem, and this creates frictions with the developers/maintainers using Jenkins. The fact that there is now 4 different version patterns that emerged in the last 2 months with CD is a very good sign that the default solution that is offered to the devs does not fit their needs and they need to keep managing their version, or some part of it, manually. IMO, you lose most of the benefits of CD if you still need to manage major/minor/patch version manually because the "generated" CD version does not have any meaning and does not handle breaking changes. I think an approach like https://github.com/jenkinsci/conventional-commits-plugin that is doing both CD and SemVer *automatically without manual intervention* or bump in code is the best of both worlds and should be the default and recommended way to use JEP-229. I don't know what is the usual approach to gather feedback of JEP from plugin maintainers and users, but I think a survey or something should be made, because I am sure many developers would use SemVer if the documentation would recommend it instead of a custom version scheme. > *Rather than traditional version numbers like 1.23 or 2.3.4 which are chosen by the maintainer, a CD release will have a version of the form 123.vabcdef456789: an integer component determined by the Git history depth, and an informational component with the Git commit hash.* On Thursday, 31 March 2022 at 12:23:41 UTC-4 [email protected] wrote: > The CD guide > <https://www.jenkins.io/doc/developer/publishing/releasing-cd/> describes > a scenario named "Manually controlled prefix*", *that outlines how to > setup an example formatted as "major.minor", but you can break it down with > ease to something like "major.minor.patch+build-hash" by modifying the > changelist format, if a plugin developer would want to do that. > > Though to note, that should be done carefully while respecting the > warnings outlined on the CD guide. > > ~ Alex > > On Thursday, 31 March 2022 at 17:53:51 UTC+2 Alex wrote: > >> I am not a Jenkins plugin developer/maintainer, but I think if there was >> a supported semVer version documented in the >> https://www.jenkins.io/doc/developer/publishing/releasing-cd/ >> documentation and officially tested, it would allow devs to choose to use >> CD with interesting labels and SemVer together. One of the example is >> https://github.com/jenkinsci/conventional-commits-plugin. Currently, >> because the SemVer pattern is not documented, `{digit}.{hash}` seems like >> the only possible option when enabling CD. >> >> On Thursday, 31 March 2022 at 04:31:52 UTC-4 [email protected] wrote: >> >>> 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/c680b944-62c8-4a9c-be8e-cf1025a823c3n%40googlegroups.com.
