Mark JEP-221 withdrawn, and JEP-229 accepted

[jglick]

AFAIK JEP-221 was never fully prototyped, much less used; the discussions surrounding it led ultimately to JEP-229, which is now in active use. @daniel-beck confirm?

[MarkEWaite]

I updated the Jenkins roadmap a few days ago to show that JEP-221 has been superseded by JEP-229 and marked it as "preview". I should have thought of this update to the JEP as well and we should probably mark it as "Released" on the roadmap.

[agaudreault]

Where can we give feedback on this ? The new CD experience is terrible.

Firs of all, it is an incomprehensible decision to not follow Semantic Versioning for software delivery nowadays. Every tools that are built integrates with semantic versioning (dependabot, renovate, dependency scanners, etc.). With this proposal, Jenkins have a custom version scheme not supported by any open source tools.

I have been doing CD in multiple projects and it is possible to follow semantic versioning with continuous delivery. Take a look at Conventional Commits convention for commit message and pull request title. This allows you to determine which part of semantic version must be bumped, without manual intervention.

Then you can integrate tools such as Semantic Release to your CI/CD workflow to get a version and generate a release.

An example of CD workflow using semver could be:

• Remove the version from Source Code

1. Pull request created and title validated with Semantic Pull Request
2. PR is squashed and merged
3. Semantic-Release runs on master build in dry-run, compare commits since latest semantic release tags and generate version
4. Semantic-Release version is injected to build tools (mvn -Dchangelist="" -Drevision=${generated_version})
5. Artifacts are pushed to registry
6. Semantic-Release runs to create release in github, generate changelog with commit history, custom code execution, etc.

This is just an example of what can be done and a few tools I have used, but CD is not an excuse not to follow largely adopted software conventions.

With the current proposal, the Jenkins plugin ecosystem regressed in usability.

Let me know what is the proper channel to give more feedback or to get involved and help improve the plugin CD workflow

[MarkEWaite]

Let me know what is the proper channel to give more feedback or to get involved and help improve the plugin CD workflow

Thanks for your interest. The Jenkins developer mailing list is a good place for those types of discussions.

[jglick]

I am aware of Conventional Commits, Semantic Release, and similar tools. The decision not to use them was deliberate. First of all, it is debatable whether SemVer really helps anything—maintainers’ notions of which changes are compatible tend to be untrustworthy compared to e.g. Dependabot success statistics or a flurry of filed regression tickets; and in the context of the Jenkins plugin manager the version number is simply an opaque comparable: you are just prompted to accept any new version (you can look at release notes if you care), and compatibleSinceVersion is used where necessary to flag potentially incompatible settings changes (typically meaning backward-compatible but not forward-compatible since the expectation is that non-backward-compatible changes should simply not be made if at all possible). In the context of CD, as opposed to some Apache library released once every two years whose changelog should be studied in depth, the idea is that there is simply a stream of changes pushed out, and problems should be “fixed forward” (excepting backports of bug fixes to plugin versions supporting older LTS lines).

At any rate, use of SemVer vs. simple numbers vs. timestamps vs. any other scheme could be left up to personal preference if plugins behaved like blobs which are only deployed somewhere but whose source code is irrelevant after the fact. That may be true for plugins which are never used as dependencies. For technical reasons involving how Maven handles project-to-project dependencies, for JEP-305 I chose a scheme which was guaranteed to supply a deterministic version number for a given commit. Schemes sensitive to the date, Git references (like branch structure), etc. do not satisfy that. It is possible other schemes can be made to work if they are thoroughly tested against the set of tools and processes we use in the Jenkins project.

If there is a specific tool or process which “does not support” the JEP-229 version scheme, I would be curious to hear about it. The scheme was chosen to work with both Maven and Jenkins version number logic (which are close but unfortunately not identical), and AFAICT works fine with Dependabot and so on.

As to a proper channel, there is nothing specifically defined for this assemblage of tools other than specific trackers like https://github.com/jenkins-infra/jenkins-maven-cd-action/issues; for Jenkins dev issues generally, there is a mailing list and a Discourse space.