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/906cee65-1338-45ae-a595-e4ab78569205n%40googlegroups.com.

Reply via email to