Sorry all, I didn't know that. In that case, I suggest we postpone till next week. Cheers, Martin On 2020-10-08 4:26 a.m., Bauman, Syd wrote:
Except that (unbeknownst to Martin), I will be attending Declarative Amsterdam tomorrow morning. Thus I may not be available until 11:30 EDT, and absolutely will need to leave by 12:10 or so for the session that starts at 12:15. (Steven Pemberton “On the design of the URL”, which I really want to attend.)
Also I will have been awake for over 10.5 hours by then with who knows how little sleep.
------------------------------------------------------------------------ Thanks everyone for your work this morning. The build jobs have all completed on the various Jenkinses, so I think we're ready to release. Syd and I are planning to do that on Friday morning, starting at:
* 08.15 PDT * 11.15 EDT * 16.15 BST * 17.15 CEST
We usually meet in Google Hangouts; anyone who wants to tag along, just let us know your Google id.
This was the Google doc where we hashed out a basic set of steps for doing a patch-release of the Stylesheets between scheduled releases:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.googl...
We also discussed renaming branches and/or Jenkins jobs as follows:
*-dev (as currently)
*-staging-x.x.x (candidate branches created for testing/evaluation before a release; version numbers would be the intended version numbers for the release when it's made)
*-released (as currently), or possibly *-stable instead
I think this helps to clarify exactly what is happening at each stage; in a normal release, you would:
- branch staging off from dev
- update VERSION file etc. (is there any etc.?)
- merge staging into released
- do the release
- merge released back into dev, then update VERSION in dev
- delete staging branch.
For an interim release, you would:
- branch staging off from released
- make the fix, test, and update the VERSION file
- merge staging into released
- EITHER: merge released into dev, OR (if that causes conflicts) try cherry-picking commits from released into dev, OR failing that, make an equivalent fix in dev.
- delete staging branch.
The complexity arises out of the fact that when you make a hotfix like this, it's possible that the dev branch is many commits ahead of the released branch, and the simple hotfix you make to solve the problem is incompatible with the current state of the dev branch, so different approaches may have to be taken to fix the problem in dev.
Does this all make sense, or have I missed anything?
-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca