[tei-council] Release Process

[James Cummings]

Hi Council,

Several suggestions were made (on IRC) about the release process 
that we go through and how we might make it more robust, open, 
and manageable.

Having a process where we freeze schema-changing commits and only 
correct prose/typos has served us well, but it has been suggested 
that we extend this and open it to the TEI community.

How about this as a strawman proposal:

2 weeks before release:
- Stop schema-affecting changes
- Freeze development on stylesheets, roma, oxgarage, etc.
- Proofread for stability/functioning of release
- Proofread for typos, bad examples, missing prose, etc.
- Only fix non-schema relating things
- Version number fixed at this point
- if something larger and release-blocking is discovered the 
clock resets to zero once the problem is solved.

1 week before release:
- Stop any changes by Council except typos
- Announce beta release on TEI-L and point them to 
lastSuccessfulArtifact on Jenkins
- Accept and correct any minor typos by public
- If anything more significant than a typo is raised that Council 
determines is release-blocking, the whole process is frozen and 
clock reset to zero once the problem is solved.

1 day before release:
- Final release notes agreed.
- Final date change
- Then SVN frozen entirely

Day of release:
- No SVN changes, only release made
- Testing of Roma and related systems after release made, but 
before announced.
- Announce release

Improvements?

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford