Thanks Martin! Looks good to me. We should not forget to add this to TCW22 after the workflow has been tested. Best, Martina -----Ursprüngliche Nachricht----- Von: Tei-council Im Auftrag von Martin Holmes Gesendet: Mittwoch, 7. Oktober 2020 00:32 An: TEI Council Betreff: Re: [Tei-council] Stylesheets meeting Tue 06 Oct 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://docs.google.com/document/d/1dI2Pwv_Fh8x5pkTX3auhTKd0qsc2wLUZpPH0-v0x... 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? Cheers, Martin On 2020-10-03 12:49 p.m., Syd Bauman wrote:

We have a Stylesheets meeting planned for Tue 06 Oct at 13:00Z; that's * 06:00 PDT * 09:00 EDT * 14:00 BST * 15:00 CEST

Unless we get off our collective rear ends and do so before then, I'm thinking perhaps we should perform the release of 7.50.1 during the meeting. This is at the moment a tiny bug fix which waiting for someone other than its authors (me & Martin) to either approve and release or at least approve for release.

One question this immediately raises, of course, is how do we do just a Stylesheets release? (I don't know -- I bet no one knows for sure, but I hope some of you have a good idea. :-)

If folks don't like that idea, please let me know ASAP so I can have something else lined up.

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

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

Martin, thanks for the great summary! I think that’s how we should proceed and only want to add GitFlow as a side note. There are several intros (I like https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) and I find especially the figures for branching etc. very helpful. I’m not saying we should adopt GitFlow in all its rigor, but the concepts are helpful and it might take away the (subversion) fear of branching ;) Cheers Peter

Am 07.10.2020 um 00:32 schrieb Martin Holmes :

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://docs.google.com/document/d/1dI2Pwv_Fh8x5pkTX3auhTKd0qsc2wLUZpPH0-v0x...

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?

Cheers, Martin

On 2020-10-03 12:49 p.m., Syd Bauman wrote:

...

We have a Stylesheets meeting planned for Tue 06 Oct at 13:00Z; that's * 06:00 PDT * 09:00 EDT * 14:00 BST * 15:00 CEST Unless we get off our collective rear ends and do so before then, I'm thinking perhaps we should perform the release of 7.50.1 during the meeting. This is at the moment a tiny bug fix which waiting for someone other than its authors (me & Martin) to either approve and release or at least approve for release. One question this immediately raises, of course, is how do we do just a Stylesheets release? (I don't know -- I bet no one knows for sure, but I hope some of you have a good idea. :-) If folks don't like that idea, please let me know ASAP so I can have something else lined up.

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council