search

hypfvieh / dbus-java

Improved version of java DBus library provided by freedesktop.org (https://dbus.freedesktop.org/doc/dbus-java/)
https://hypfvieh.github.io/dbus-java/
MIT License
185 stars 73 forks source link

Modified the POM files to be more CI/CD friendly #199

Closed drivera73 closed 1 year ago

drivera73 commented 1 year ago

In the new CI/CD world, it's easier to set a version for a specific build by just setting -Drevision=... and invoking the build. This significantly facilitates the whole versioning paradigm since the version is now only stored in a single, centralized place.

Now, whenever a version bump is needed, only the "master" value in the root pom.xml needs to be updated. This should only affect the build process.

See https://maven.apache.org/maven-ci-friendly.html for more details on ${revision}, ${changelist}, and ${sha1} and their usefulness in the modern, CI/CD world.

hypfvieh commented 1 year ago

Sorry, I don't get it. The build process using maven is just fine without this PR. Parametrizing the version number is possible without additional plugins. But I don't see any substantial improvement doing that.

The version stays like it was until I decide to create a release. Maven will then update the versions on all required occasions without any additional help.

There is also no real CI/CD for this project as it is simply not necessary. Github Actions will be executed on each commit to verify unit tests still pass. Sadly enough the tests fail randomly in Github Actions due to timeout issues or something like that which cannot be reproduced locally.

If one needs to use a "unreleased" beta-snapshot version, anyone is free to download the sources and build it. There is no snapshot deployment anywhere and I don't plan to change that (anyway, this would also re-use the same version until a release is performed).

I also did never see this kind of setup in any project I've been involved or where I took closer look at the build process.

drivera73 commented 1 year ago

Fair enough. I use this in several projects at work and have found it extremely convenient for version management. But you're right - the most useful aspect is when you're cutting builds that need to also automatically be pushed out to a runtime environment (i.e. beta builds, release candidates, timestamped builds, etc), and you want to be sure said build has a distinctive version number, without necessarily having to record it in SCM (b/c there's a tag associated, no commit of the new version number is really needed).

I just figured I'd propose it on the off chance you'd be interested.

Overall, this PR shouldn't change any of the build processes you've become accustomed to - it just makes it easier to modify the version via the ${revision} parameter.

hypfvieh commented 1 year ago

I'll close this, because I don't think this changes would help with anything in this particular case. Thanks anyway.