Publish nightly snapshots

[Arthurm1]

Is your feature request related to a problem? Please describe.
QuickFixJ isn't released that often but there are often new commits that may have already fixed any issue I might currently have.

I'm experiencing the same as this stackoverflow issue and I'd like to test unreleased versions of QuickFixJ to see if they fix my problem.

Describe the solution you'd like
I'd like to see snapshots posted to a public repo whenever a new PR has been merged. That means I can easily test to see if my issue has been fixed.

Describe alternatives you've considered
I could build from source but that does involve a number of steps. It also doesn't allow me to easily switch between a number of snapshots to check which fixes my issue.

Another option would be more frequent proper releases of QuickFixJ but I imagine that's a lot of overhead for you to support.

[chrjohn]

Hi @Arthurm1 , I thought about this myself some time ago...
Currently I don't have much time to look into this, but I could imagine that there already is some github action that would do that for me. Maybe you could check if you find something useful? Otherwise I'll look into it whenever I have the time.

[Arthurm1]

@chrjohn Sadly I don't use Maven or github for publishing. I'm struggling to work out how you're currently using github for publishing or do you run the process locally/manually.

[chrjohn]

There is a scheduled run every morning.

quickfixj/.github/workflows/maven.yml

Line 8 in d7c9fe5

schedule:

For releases we use Sonatype which also have a snapshot repo.
Maybe we can change the scheduled run to upload a snapshot daily. But need to figure out that it is not done on every pull request run.

[the-thing]

@chrjohn

Wouldn't it be better to have additional workflow for that? There seem to be a solution suggested here https://github.com/orgs/community/discussions/27128

It seems to trigger only when there was an actual commit in the last 24h, which might be desired not to publish unchanged artifacts, but also a possible problem when a nightly build fails due to a flaky test (there would have to be a new commit to master branch so the next day build pick it up).

[chrjohn]

@the-thing sounds reasonable. Thanks for checking. 👍

[chrjohn]

Thought a little more about this. Probably the easiest would be if we just upload a snapshot each day regardless of whether there was a change in the last 24 hours or not.

[chrjohn]

Reading further on this topic it seems that SNAPSHOT version are not allowed anymore on Sonatype/Maven Central. So probably will either do a nightly release each day (which would be shown here https://github.com/quickfix-j/quickfixj/releases ) or to upload to Github Packages.
Probably the latter is more favourable. People would need to modify their settings.xml (see https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry ) but it would do all the maven magic like downloading dependencies. If we do a nightly release it would be a binary distribution which I'm thinking about to ditch anyway (see #734).

Any thoughts @Arthurm1 @the-thing ?

Thanks

[the-thing]

This sounds good to me. I would release the nightly build to GitHub Maven repository and keep current release unchanged and possibly remove this zip release file.

[MartyIX]

It would be great to have this.

Especially since MINA in the latest released version of quickfixj does not support TLS 1.3.

[chrjohn]

Any help moving this forward (upload to github packages that is) is greatly appreciated. Currently stuck in other projects and vacation. ;)

[david-gibbs-ig]

@chrjohn it looks like you are right about the Maven Central and SNAPSHOTS, this inconvenient. I think it might be possible to work around that by overriding release version in the pom using :

• mvn versions plugin

  https://stackoverflow.com/questions/5726291/updating-version-numbers-of-modules-in-a-multi-module-maven-project
  https://www.mojohaus.org/versions/versions-maven-plugin/examples/set.html

• mvn versions plugin
  https://maven.apache.org/maven-release/maven-release-plugin/usage/update-versions.html

maven build helper plugin can parse the existing version

• https://www.mojohaus.org/build-helper-maven-plugin/plugin-info.html

Current branch name can be retrieved in github actions

• https://www.geeksforgeeks.org/get-current-branch-name-in-github-actions/
• https://pwgen88.medium.com/getting-branch-name-in-github-actions-based-on-workflow-trigger-1d10b8515d37

It looks possible to get build number as well

• https://www.geeksforgeeks.org/get-build-number-in-github-actions/

Perhaps for branches that are NOT 'main|master' a release could be made with a contrived version name like
<major>.<minor>.<patch>.<build-number>-<qualifier> with branch name as the qualifier
e.g. 3.0.0.1.my-branch-name

• https://octopus.com/blog/maven-versioning-explained

This can be done without committing amended poms, they can stay within the GitFlow scheme. This workaround is fairly horrible and would require house keeping but perhaps it can be considered as workaround. They do not seem to be in a hurry to implement snapshot support. PS snapshots without qualification are not very useful for a project with multiple active branches like QFJ anyway as any snapshot build overwrites predecessors.

One needs the build number because : https://central.sonatype.org/faq/can-i-change-a-component/
Actually one cannot even do housekeeping : https://central.sonatype.org/faq/can-i-change-a-component/

Probably everything I wrote is a waste of time and one just has to work with snapshots locally and builds for things that are in progress with fail until releases are made. To verify a PR for a project with SNAPSHOT dependencies probably means checking it out and building it locally. :-(

[McKratt]

@chrjohn it looks like you are right about the Maven Central and SNAPSHOTS, this inconvenient. I think it might be possible to work around that by overriding release version in the pom using :

• mvn versions plugin
  https://stackoverflow.com/questions/5726291/updating-version-numbers-of-modules-in-a-multi-module-maven-project
  https://www.mojohaus.org/versions/versions-maven-plugin/examples/set.html
• mvn versions plugin
  https://maven.apache.org/maven-release/maven-release-plugin/usage/update-versions.html

maven build helper plugin can parse the existing version

• https://www.mojohaus.org/build-helper-maven-plugin/plugin-info.html

Current branch name can be retrieved in github actions

• https://www.geeksforgeeks.org/get-current-branch-name-in-github-actions/
• https://pwgen88.medium.com/getting-branch-name-in-github-actions-based-on-workflow-trigger-1d10b8515d37

It looks possible to get build number as well

• https://www.geeksforgeeks.org/get-build-number-in-github-actions/

Perhaps for branches that are NOT 'main|master' a release could be made with a contrived version name like <major>.<minor>.<patch>.<build-number>-<qualifier> with branch name as the qualifier e.g. 3.0.0.1.my-branch-name

• https://octopus.com/blog/maven-versioning-explained

This can be done without committing amended poms, they can stay within the GitFlow scheme. This workaround is fairly horrible and would require house keeping but perhaps it can be considered as workaround. They do not seem to be in a hurry to implement snapshot support. PS snapshots without qualification are not very useful for a project with multiple active branches like QFJ anyway as any snapshot build overwrites predecessors.

One needs the build number because : https://central.sonatype.org/faq/can-i-change-a-component/ Actually one cannot even do housekeeping : https://central.sonatype.org/faq/can-i-change-a-component/

Probably everything I wrote is a waste of time and one just has to work with snapshots locally and builds for things that are in progress with fail until releases are made. To verify a PR for a project with SNAPSHOT dependencies probably means checking it out and building it locally. :-(

I think, the idea is smart but so far away of the Maven standard that I don't think any dev coming searching a nighty version will understand what he should take as version. More than that, this will create a lot of versions which will blur a bit more the version pattern and then the dev experience.

[McKratt]

@chrjohn Let me summarize what we need here to check if I understood well.
We need a new Github workflow on master that will run every day and publish a SNAPSHOT version on Github Package.
Did I understand the discussion correctly ?