jenkinsci / apache-httpcomponents-client-5-api-plugin

Bundles Apache HttpComponents Client 5.x and allows it to be used by Jenkins plugins.
https://plugins.jenkins.io/apache-httpcomponents-client-5-api
MIT License
1 stars 2 forks source link

Enabled CD #48

Closed vwagh-dev closed 5 months ago

vwagh-dev commented 5 months ago

Testing done

Submitter checklist

jtnord commented 5 months ago

It would remove the ability to have a semantic version for this plugin which is useful as it is connected to the version of the bundled httpclient5 lib.

this is not the case - and this is retained in the PR - the revision is specifically still tied to the version of the library - everything else comes after as a qualifier so semver is retained, which is exactly the same as the current release versions.

The only difference should be that the versions x.y.z-a.b a would not restart at zero for each bump in z but this still adheres to semver.

for an example see the releases caffeine-api plugin

strangelookingnerd commented 5 months ago

Waiting for https://github.com/jenkins-infra/repository-permissions-updater/pull/3980 to be merged.

jtnord commented 5 months ago

It would remove the ability to have a semantic version for this plugin which is useful as it is connected to the version of the bundled httpclient5 lib.

this is not the case - and this is retained in the PR - the revision is specifically still tied to the version of the library - everything else comes after as a qualifier so semver is retained, which is exactly the same as the current release versions.

To avoid any confusion, loosing semver is not the case with how CD is implemented here, as it is following Versioning with wrapped components (optional) from the docs

if you are enabling / reviewing CD on other repos, you need to follow this path, otherwise you will get non semver versions for api plugins.

You can always check by running mvn validate -Dset.changelist -Dignore.dirt and seeing what version it creates.

strangelookingnerd commented 5 months ago

To avoid any confusion, loosing semver is not the case with how CD is implemented here, as it is following Versioning with wrapped components (optional) from the docs

if you are enabling / reviewing CD on other repos, you need to follow this path, otherwise you will get non semver versions for api plugins.

You can always check by running mvn validate -Dset.changelist -Dignore.dirt and seeing what version it creates.

Thanks for the clarification, it’s been a while since I looked at that topic. It indeed makes life easier for library plugins.