eXist-db / documentation

Documentation of eXist
13 stars 44 forks source link

[suggestion] automate releases from CI #939

Open duncdrum opened 9 months ago

duncdrum commented 9 months ago

Is your feature request related to a problem? Please describe. manual releases are error prone and tedious.

Describe the solution you'd like automatic releases to be executed when merging to develop branch

Describe alternatives you've considered change nothing and stick with current behaviour

adamretter commented 9 months ago

How would you automate pinning the correct documentation version against the correct/corresponding eXist-db version?

duncdrum commented 9 months ago

in principle in the same way we automate releases in other org repos. Through commit message conventions, which are enforced by linting.

A PR that bumps exist-db processor dependency will be a BREAKING CHANGE and needs to be named accordingly.

adamretter commented 9 months ago

Could you described how this would actually work in practice... I am still not clear if this is actually practical.

For example:

  1. I want to make changes to the documentation for eXist-db 6.x.x, how should that be done, what branches etc, and how does it know which version of eXist-db 6.x.x the documentation should be built and published for (including updating the processor dependency in expath-pkg.xml). How can it check that my documentation changes are not changes that only apply to a newer version of eXist-db?
  2. Simultaneously the same question for eXist-db versions 4.x.x, 5.x.x, and 7.x.x.?
duncdrum commented 9 months ago

Your questions don't seem to be about the automation of releases from develop to master but about a multi-branch architecture with cherry pricked releases for different exist versions.

We currently don't do that and haven't in the past. We could however maintain multiple release branches targeting major exist versions , each with their own automation. However as we don't do that now, my plan is that custom releases should still happen manually.

The first step is to get maven to behave and keeping it happy in the simple case of develop and master. I have ideas for how to deal with multiple branches, but step by step.

adamretter commented 9 months ago

don't seem to be about the automation of releases from develop to master

They weren't as I didn't see anything in the description of your issue above that indicated that that was what you were aiming for! It seems I may have misunderstood, and assumed something else; understandable I think as there is not much detail here. Also as the documentation repo doesn't have a develop branch, I am not sure that that is relevant here anyway.

When you have the time, I think some more written detail and clarity around what you are looking for in this issue would help everyone involved...