afs opened a new pull request, #119: URL: https://github.com/apache/jena-site/pull/119
We get changes for the website that are changes to go into the next release. There are also changes that should go out immediately. So there are two workflows. Currently, release-changes get held as approved PRs. This is workable but the approved PRs aren't checked against each other or for PRs-to-PRs. An alternative is to have a branch for accumulated changes for the next release. We should make it the default branch because tooling tends to end up with PRs to the default branch. Keep `main` for this. There is a `publish` is a new branch from which the currently deployed website. On a release, merge `main` into `publish`. The burden is than on website fixes. They need to go to `publish`. We can edit the target PRs through GH UI. So with this change, we have two branches. And probably so friction if a PR goes to `main` instead of `publish`. We can cherry-pick but it is a different commit. `merge` when publishing the next version may get this right, or it may not. This PR is the one-line `Jenkinsfile` change (untested). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jena.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
