[JEP-229] Plugin CD workflow version scheme

[Alex]

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.

[Gavin Mogan]

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.

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6c870d41-9754-4e14-81d5-b9ff631fde78n%40googlegroups.com.

[Alexander Brandes]

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. 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

[Alex]

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.

[Alexander Brandes]

The CD guide 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

[Alex]

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.

[Gavin Mogan]

I will say that deploying with a plugins.txt + using renovate, I get
changelogs for all plugin updates as PR minutes.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c680b944-62c8-4a9c-be8e-cf1025a823c3n%40googlegroups.com.