Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[suggestion] automate releases from CI #939

Open
duncdrum opened this issue Dec 19, 2023 · 5 comments
Open

[suggestion] automate releases from CI #939

duncdrum opened this issue Dec 19, 2023 · 5 comments
Assignees

Comments

@duncdrum
Copy link
Contributor

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

@duncdrum duncdrum self-assigned this Dec 19, 2023
@adamretter
Copy link
Contributor

adamretter commented Dec 19, 2023

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

@duncdrum
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants