@javahippie and I have colaborated today on establishing a release pipeline. Tim had the great idea that we start with the migrate-from-camunda-recipe repository, because builds are there fast and we can establish there the build soon. When this is working we should be able to transfer this to the main repo easily.
I’ll work on this now further and can hopefully give an update soon.
3 Likes
Great, looking forward to the beta-2 release 
I got a bit further. JReleaser has produced a “pre-release”. I have to stop for now. Will continue later.
1 Like
This drove me almost nuts. But finally the first artifact is published via JReleaser 
3 Likes
I’ve also started backporting cibseven commits. Would be cool if we could have one label for c7 backports and one label for cibseven backports and put these in our release notes.
JReleaser works on the level of commit messages. If the message body would contain a reference that can be used to label and categorize these commits, then we would be able to list that in the Changelog
1 Like
Ah, I understand. So this should work as matcher:
Backported commit .* from the camunda-bpm-platform repository.
Backported commit .* from the cibseven repository.
Is it important for the release notes that the commits were backported? 
. You’re right listing them separately does not make sense. A bugfix is a bugfix, doesn’t matter if it was backported.
Perhaps we should rather write a few sentences about the release like: “We’re now on a functional level of C7.22.1” just to let people know that we’re doing the backports
Can you write free text to the release notes with the JReleaser flow?
We will have to write some kind of “New and noteworthy” about a release into a template file. I did this as an example in migrate-from-camunda-recipe.
1 Like
I will spend this Friday on making progress on the release process. I don’t expect that this will be done by then, but we will definitely make progress. With the first release I learned quiet something about how JReleaser works, the GitHub workflows, how to test some parts locally, debugging. This will pay off now.
Depending on the outcome we can slowly think about a timeline that we can announce. My feeling is that we will be able to make our consumers a christmas present 
2 Likes
Once beta-2 is released, I’ll be able to rebase our distribution on it. At the moment, we’re building everything directly from the main branch. If everything works smoothly after the rebase, I think there are only a handful of issues left to tackle before a 1.0.0 release.
One question remains: what’s the current status of the documentation? It would be fantastic if we could release the documentation alongside 1.0.0. It would really help to give the release a polished feel.
In today’s Live Coding session I made some progress on working on the release process. It is still some way to go. I will have some time later today again.
1 Like
I’m tweaking last things on the release workflow. It is mostly ready to the point that it actually would run against the remote services. Of course things can go badly wrong there again.
But if nothing speaks against it I would finally perform the release workflow soon.
2 Likes
Nice! Just ping me when you did the release, i can test it with our software.
1 Like