CETEIcean 1.7.1 → 1.7.2

Sign up to get free protection for your applications and to get access to all the features.
Files changed (17) hide show
  1. package/package.json +1 -1
  2. package/src/CETEI.js +5 -5
  3. package/tutorial_en/README.md +7 -3
  4. package/tutorial_ja/README.md +202 -0
  5. package/tutorial_ja/css/tei.css +8 -0
  6. package/tutorial_ja/example/css/tei.css +98 -0
  7. package/tutorial_ja/example/index.html +36 -0
  8. package/tutorial_ja/example/index_ja.html +47 -0
  9. package/tutorial_ja/fpn-washington.xml +9893 -0
  10. package/tutorial_ja/js/CETEI.js +871 -0
  11. package/tutorial_ja/meros.xml +675 -0
  12. package/.vscode/settings.json +0 -6
  13. package/test/P5.css +0 -362
  14. package/test/tcw20.html +0 -960
  15. package/test/tcw22.xml +0 -468
  16. package/tutorial_es/Ruy_Diaz-La_Argentina_Manuscrita.tei.xml +0 -11579
  17. package/xslt/make-CETEIcean-3.xsl +0 -81
package/test/tcw22.xml DELETED
@@ -1,468 +0,0 @@
1
- <?xml version="1.0" encoding="UTF-8"?>
2
- <TEI xmlns="http://www.tei-c.org/ns/1.0">
3
- <teiHeader>
4
- <fileDesc>
5
- <titleStmt>
6
- <title>Building a TEI Release</title>
7
- <author xml:id="MDH">Martin Holmes</author>
8
- <author>James Cummings</author>
9
- <author>Lou Burnard</author>
10
- <author>Sebastian Rahtz</author>
11
- <author>David Sewell</author>
12
- <author xml:id="KSH">Kevin Hawkins</author>
13
- <author xml:id="HC">Hugh Cayless</author>
14
- <author xml:id="PS">Peter Stadler</author>
15
- <author xml:id="EM">Elli Mylonas</author>
16
- <author xml:id="EBB">Elisa Beshero-Bondar</author>
17
- <author xml:id="RV">Raffaele Viglianti</author>
18
- <author xml:id="JL">Jessica H. Lu</author>
19
- </titleStmt>
20
- <publicationStmt>
21
- <publisher>TEI Technical Council</publisher>
22
- <date>2018</date>
23
- </publicationStmt>
24
- <sourceDesc>
25
- <p>This document was originally a section of tcw20.xml, but has now been spun off into its
26
- own document.</p>
27
- </sourceDesc>
28
- </fileDesc>
29
- <revisionDesc>
30
- <change when="2020-02-13" who="#JL">Additional changes based on February 2020 release to make links visible, clarify release steps, confirm primacy of Paderborn Jenkins server.</change>
31
- <change when="2020-02-13" who="#JL">Update all references, and add links, to Jenkins servers. Revise instructions regarding release version numbers.</change>
32
- <change when="2020-02-10" who="#EBB">Update all references about ssh to the tei server to the new HumaNum server consistently. Correct small grammatical errors.</change>
33
- <change when="2019-02-04" who="#EM">Add updates and clarifications learned from last release.</change>
34
- <change when="2019-01-30" who="#PS">Add information about setting JAVA_HOME for updating the Debian packages</change>
35
- <change when="2019-01-29" who="#sb">Be explicit about contacting Jenkins maintainers ahead of time</change>
36
- <change when="2016-09-25" who="mt">Recommendations for issue handling that facilitate preparing the Release Notes.</change>
37
- <change when="2016-04-02" who="#MDH">Beginning edits arising out of the experiences
38
- releasing 3.0.0. More to come.</change>
39
- <change when="2016-03-16" who="#KSH">Fixed error in git command as just reported on
40
- tei-council</change>
41
- <change when="2016-02-23" who="#HC">Edits for new release process.</change>
42
- <change when="2015-12-14" who="#MDH">Updates for new Jenkins server subdomains.</change>
43
- <change when="2015-10-07" who="#MDH">Update for use of ant build process for oxygen-tei rather
44
- than the old .sh file.</change>
45
- <change when="2015-10-04" who="#MDH">More updates to account for the shift from SF SVN to
46
- GitHub.</change>
47
- <change when="2015-10-03" who="#MDH">Updates to account for the shift from SF SVN to
48
- GitHub.</change>
49
- <change when="2015-04-06" who="#MDH">Updates arising out of release process for 2.8.0.</change>
50
- <change when="2015-04-06" who="#KSH">Added link to http://wiki.tei-c.org/index.php/IRC</change>
51
- <change when="2015-04-04" who="#MDH">Updates to take account of oxygen-tei's move from Google
52
- Code to GitHub, along with a couple of other tweaks.</change>
53
- <change when="2014-01" who="#MDH">Updates for changes in procedure ahead of the 2.6.0
54
- release.</change>
55
- <change when="2013-11" who="#MDH">Updates following move of some code from SourceForge to
56
- GitHub, and automation of the P5 version number in output.</change>
57
- <change when="2012-10-25" who="#MDH">Updates following Primrose Path release
58
- experience.</change>
59
- <change when="2012-07-24" who="#KSH">Newsfeed blog is no longer in SourceForge.</change>
60
- <change when="2012-06-28" who="#KSH">A few changes based on messages to tei-council on
61
- 2012-06-19 and 2012-06-20.</change>
62
- <change when="2012-06-19" who="#KSH">Improvements suggested by various Council members based on
63
- experiences with version 2.1.0.</change>
64
- <change when="2012-06-16" who="#KSH">Explained version numbers and added reminder about
65
- including readme file in announcement.</change>
66
- <change when="2012-02-02" who="#MDH">Document forked from tcw20.xml.</change>
67
- </revisionDesc>
68
- </teiHeader>
69
- <text>
70
- <body>
71
-
72
- <p>This document aims to provide a set of detailed instructions enabling a "release
73
- technician" (the Council member tasked with implementing a new release of the TEI) to
74
- prepare for and manage the release process. It assumes that the new packages will be taken
75
- from one of the Jenkins servers rather than being built locally by the release technician.
76
- This is easier and more reliable, because we ensure that the Jenkins servers are regularly
77
- updated and are correctly configured to build the TEI products.</p>
78
-
79
- <div xml:id="githubPackages">
80
- <head>Packages on GitHub</head>
81
- <p>The TEI maintains a number of distinct repositories on GitHub under the
82
- <ref target="https://github.com/TEIC">TEIC</ref> organization. The main repository for developing the P5 Guidelines
83
- and associated schemas is <ref target="https://github.com/TEIC/TEI">TEIC/TEI</ref>, and the TEI Stylesheets, the code for
84
- the Roma web application, and the source code for the Oxygen TEI plugin can be found in
85
- <ref target="https://github.com/TEIC/Stylesheets">TEIC/Stylesheets</ref>,
86
- <ref target="https://github.com/TEIC/Roma">TEIC/Roma</ref>, and
87
- <ref target="https://github.com/TEIC/oxygen-tei">TEIC/oxygen-tei</ref> respectively. </p>
88
- <p>The rest of this section describes how to make a new release for the main
89
- <ident>P5</ident> package, but similar procedures apply to the others. The instructions
90
- assume you are working on a Linux or MacOSX system with a command line, and know (more or
91
- less) how to do basic command-line operations such as running scripts and logging into a
92
- server with ssh.</p>
93
- </div>
94
-
95
- <div xml:id="beforeStarting">
96
- <head>What you will need before you start</head>
97
-
98
- <list type="bulleted">
99
- <item>An account on GitHub, and committer privileges over the TEI repository. If you have
100
- ever pushed a change to the TEI repository, you should have all the
101
- required permissions.</item>
102
- <item>Shell access on the TEI SourceForge project. Contact one of the admins to have this
103
- turned on. Normal committers don't have shell access.</item>
104
- <item> The release manager will need SSH login access to the tei account on the tei-c.org
105
- server. This involves two steps: <list type="ordered">
106
- <item>Generate an SSH key pair (if you don't have one already). If this is new to you,
107
- look at <ref target="https://en.wikipedia.org/wiki/Ssh-keygen"
108
- >https://en.wikipedia.org/wiki/Ssh-keygen</ref>.</item>
109
-
110
- <item>Send the public key to the Council Chair, who will forward it on to the system
111
- administrator.</item>
112
- </list> Make sure you get this set up well in advance of the release day, and make sure
113
- you can ssh tei@cchum-kvm-dockerteic.in2p3.fr successfully. </item>
114
-
115
- <item>Some familiarity with the three TEI Jenkins Continuous Integration Servers.
116
- <list type="ordered">
117
- <item><ref target="https://jenkins.tei-c.org">https://jenkins.tei-c.org</ref></item>
118
- <item><ref target="https://jenkins2.tei-c.org">https://jenkins2.tei-c.org</ref></item>
119
- <item><ref target="https://jenkins3.tei-c.org">https://jenkins3.tei-c.org</ref></item>
120
- </list>
121
- Take a little time to watch them work, and see how a push to the GitHub
122
- repository causes them to start building TEI packages. There are three specific build
123
- jobs associated with P5, and they run in a fixed sequence. Currently, as of February 2020,
124
- the actual build for the release will rely on the first Jenkins server, often referred to as
125
- the "Paderborn Jenkins" (maintained by Peter Stadler in Paderborn, Germany).</item>
126
- <item>Access to the <ref target="https://tei-c.slack.com">TEI Council Slack</ref>
127
- which will be the communication channel during the release process.</item>
128
- <item>Several hours of time. You won't be busy all the time, but the process from
129
- beginning to end takes several hours, especially if something goes a bit wrong and you
130
- have to retrace your steps. It's best to start first thing in the morning, and prepare
131
- to be busy all day.</item>
132
- </list>
133
- <list>
134
- <item> A copy of the public key that will enable you to sync the release zip with
135
- SourceForge. <list>
136
- <item>log in to the tei server at ssh tei@cchum-kvm-dockerteic.in2p3.fr (this requires that you've completed
137
- the other public key step above).</item>
138
- <item><code>cat ~/.ssh/id_rsa.pub</code> and copy the contents to the clipboard.</item>
139
- <item>paste the result into a text editor and remove any linebreaks added by the
140
- terminal.</item>
141
- <item>copy-paste the result into https://sourceforge.net/auth/shell_services</item>
142
- </list> What this does is to enable you (when logged in as tei to tei-c.org) to connect
143
- to SourceForge (as your SF user) to upload the release files. </item>
144
-
145
- <item>Test it by trying to log into SourceForge via ssh from the tei-c.org server:<lb/>
146
- <code>ssh sfuser,tei@frs.sourceforge.net</code><lb/> where "sfuser" is your SourceForge
147
- user name. You should not see a prompt for a password (because of the ssh keys you have
148
- set up). Instead, you should immediately see <q>Welcome! This is a restricted Shell
149
- Account. You can only copy files to/from here.</q> If you see this, then everything is
150
- set up correctly.</item>
151
-
152
- </list>
153
- </div>
154
-
155
- <div xml:id="issueHandlingGuidelines">
156
- <head>Issue Handling Recommendations</head>
157
- <list type="unordered">
158
- <item>Assign tickets to release milestone</item>
159
- <item>Use ticket reference in any commits addressing or fixing the issue</item>
160
- <item>At least for the final commit addressing the issue try to prepare the commit message so it can be used for Release Notes</item>
161
- <item>Label the issue as Release Note (green label) if it’s important to include the note about it in Release Notes</item>
162
-
163
- </list>
164
- </div>
165
-
166
- <div xml:id="releaseSteps">
167
- <head>Step-by-step instructions</head>
168
-
169
- <list type="ordered">
170
- <head>1-2 weeks before release:</head>
171
- <item>Inform the Jenkins maintainers (who may not be on the Council listserv), and the
172
- TEI sysadmin, of the pending release date, so that they can be available or on-call. </item>
173
- <item>Ask one of the Jenkins maintainers (Peter Stadler, Martin Holmes, and Raffaele Viglianti)
174
- to run a link check on the Guidelines and fix broken links in the dev branch. </item>
175
- <item>Ask for the TEI-C GPG key passphrase. You'll need it for signing the Debian packages.
176
- (The GPG private key itself is hosted on the server at the default location.)</item>
177
- <!-- Revisit the above item, which was called into question during February 2020 release.
178
- If Debian package update is not the responsibility of release technician(s),
179
- and is actually handled by Peter Stadler, this step is not necessary. (JL, 2020-02-13) -->
180
- <item><hi rend="bold">Communicate with the TEI Council chair to make sure that the P5/ReleaseNotes/readme-X.X.X.xml
181
- is compiled</hi><lb/> Normally, this will be created by the TEI Council chair at the
182
- point when the repository moved from its "alpha" stage to "beta", following these steps: <list>
183
- <item>Confirm the version number for the new release in consultation with Council. TEI
184
- version numbers are based on the Unicode Consortium system (<ref target="http://www.unicode.org/versions/"
185
- >http://www.unicode.org/versions/</ref>) but with the first digit for major
186
- changes, the second for schema-changing revisions, and the third for
187
- non-schema-changing revisions. When the first or second digit is incremented, the
188
- following digit or digits is set to zero. During initial development, the version
189
- number is followed by "alpha"; during the pre-release checking stage, it's followed
190
- by "beta"; and when the release takes place, "beta" is removed and the version
191
- number has only digits and periods.</item>
192
- <item>Create the new file by cloning a previous one.</item>
193
- <item>Consult the git log log to check for all the significant changes since the last
194
- release. You can do this by opening a terminal in the root of a working copy of the
195
- TEI repository and running:<lb/>
196
- <code>git log --after=2015-08-01</code><lb/> where the date is that of the previous
197
- release. </item>
198
- <item>Add the new file into the repository with <code>git
199
- add</code>.</item>
200
- </list>
201
- </item>
202
- <item>At least one week before releasing, we enter a review period, during which the only
203
- changes made to the code to be released should be to fix errors, rather than to add new
204
- features. A release branch will be created by the release technician, to which ONLY
205
- release-blocking bug fixes and corrections to typographical errors will be pushed. The
206
- release technician should announce a temporary hold on pushes to the dev branch on the
207
- Council list, then create the branch and push it to GitHub using the following commands:
208
- <lb/><code>git checkout dev</code> (make sure you start from the dev branch) or if you have the dev branch
209
- checked out, <code>git status</code> in order to make sure that you have the current version and no uncommited changes.
210
- <lb/><code>git checkout -b release-X.X.X</code>
211
- <lb/><code>git push -u origin release-X.X.X</code></item>
212
- <item>Immediately after the release branch has been pushed,
213
- the release technician should inform the <ref
214
- target="mailto:tei-council@lists.tei-c.org">Council
215
- list</ref> and ask the maintainers of the TEI Jenkins
216
- systems to add a build of the release branch so that commits
217
- pushed there are properly tested, and advise them of the
218
- release schedule. Remember that the maintainers (currently
219
- Martin Holmes, Peter Stadler, and Raffaele Viglianti) may not be on the Council
220
- list. Verify with the maintainers that all Jenkins servers are functioning properly. </item>
221
- <item>Pushes to the release branch should be merged back into dev regularly:
222
- <lb/><code>git checkout dev</code>
223
- <lb/><code>git merge release-X.X.X</code></item>
224
-
225
- </list>
226
- <list type="ordered">
227
- <head>On release day:</head>
228
- <item>The instructions below for Git commands are assumed to be run in the release-X.X.X
229
- branch unless otherwise specified. If you did not create the release branch, you can
230
- set up a copy of it using the following commands:<lb/>
231
- <code>git pull origin</code> (to make sure your copy knows about the release branch)<lb/>
232
- <code>git checkout --track origin/release-X.X.X</code>
233
- </item>
234
- <item>Check the release notes for typos or other glaring errors, one last time.</item>
235
- <item><hi rend="bold">Edit the P5/VERSION file to the correct number</hi><lb/> This file
236
- consists only of the bare version number, followed by "alpha" or "beta":<lb/>
237
- <code>2.8.2beta</code><lb/> For the release process, you need to remove the letters from
238
- the end, leaving a pure version number:<lb/>
239
- <code>2.8.2</code><lb/> This changes the release from beta (or possibly alpha) to the
240
- actual release version number. </item>
241
-
242
- <item><hi rend="bold">Announce a freeze on pushes to the release branch on the
243
- TEI Technical Council mailing list</hi></item>
244
- <item><hi rend="bold">Merge the release branch into <code>released</code></hi>. <lb/>
245
- <code>git checkout released</code><lb/>
246
- <code>git merge --no-ff -m "YOUR COMMIT MESSAGE" release-X.X.X</code></item>
247
- <item><hi rend="bold">Repeat the steps above for the Stylesheets</hi> (have a stylesheets expert on hand
248
- when releasing Stylesheets to help debug problems):
249
- <list type="ordered">
250
- <item>Edit the Stylesheets/VERSION number to the correct release number (usually just
251
- remove the 'a').</item>
252
- <item>Run <code>make log</code> to generate the changelog. Then commit the changes.</item>
253
- <item>Merge the release branch into <code>released</code><lb/>
254
- <code>git checkout released</code><lb/>
255
- <code>git merge --no-ff -m "YOUR COMMIT MESSAGE" release-X.X.X</code>
256
- </item>
257
- </list>
258
- </item>
259
- <item><hi rend="bold">Push your changes</hi> for both P5 and the Stylesheets to the git
260
- repository, <code>git push origin released</code><lb/> and watch Jenkins build P5 for you.<lb/>
261
- This should be the final push for this version, and it will trigger the Jenkins servers
262
- to rebuild the TEI packages. As a reminder, you can find the Jenkins servers here:
263
- <list>
264
- <item><ref target="https://jenkins.tei-c.org">https://jenkins.tei-c.org</ref></item>
265
- <item><ref target="https://jenkins2.tei-c.org">https://jenkins2.tei-c.org</ref></item>
266
- <item><ref target="https://jenkins3.tei-c.org">https://jenkins3.tei-c.org</ref></item>
267
- </list>
268
- And now you wait while the Jenkins servers build the packages, keeping in mind that
269
- subsequent steps will require the build packages from the Paderborn Jenkins server
270
- (as of February 2020). This can take a couple of hours, so be patient.
271
- <!-- As of February 2020, the following sentence, which previously appeared in the TCW,
272
- was proven false.
273
-
274
- "All of the Jenkins servers should behave
275
- identically, and they should all build all three TEI packages successfully." (RV, EB, JL, 2020-02-13) -->
276
- <hi rend="bold">Note</hi>: The P5 and Stylesheets builds have reciprocal dependencies,
277
- so the first build of either the Stylesheets or the Guidelines may fail just because
278
- there isn't yet a current build of the other for it to use. This isn't a cause for
279
- panic, but it may mean that (e.g.) the Stylesheets build needs to run twice. In particular,
280
- the Stylesheets build may fail after the TEI release is complete, so it is better to wait
281
- until the TEI release is complete before doing the Stylesheets release. (Council is considering
282
- changing how the dependency is managed).</item>
283
- <item><hi rend="bold">Ensure all changes have been committed, built, and successfully
284
- passed tests on the continuous integration server</hi><lb/> When all builds have
285
- completed on all Jenkins servers, click on the job number of the last build for each of the
286
- three TEI jobs to make sure that it was triggered by the commit that you made in the
287
- previous step (you should see your own commit message on the build page). Make sure that
288
- all builds were successful (they should have green balls next to them). In the case of red balls,
289
- indicating a failed build, seek support via the TEI Council Slack. </item>
290
- <item>
291
- <hi rend="bold">Log into TEI server and run the tei-install.sh script:</hi><lb/>
292
- Log into the TEI server via <code>ssh tei@cchum-kvm-dockerteic.in2p3.fr</code>
293
- and fetch the current version of the install script by issuing
294
- <code>curl https://raw.githubusercontent.com/TEIC/TEI/dev/P5/Utilities/tei-install.sh -o ~/tei-install.sh</code>.
295
- <lb/> (If you'll need to tweak that script later during the install process please make
296
- sure to feed the changes back to the original script in the TEI repo.)
297
- <lb/> Do the following three steps: <list>
298
- <item>Install on tei-c.org: <code>./tei-install.sh --package=TEIP5 --version=X.X.X
299
- --sfuser=username --install</code> and then <emph>go test the version this puts in
300
- the Vault</emph>.</item>
301
- <item>If that looks good and everyone agrees then: <code>./tei-install.sh
302
- --package=TEIP5 --version=X.X.X --sfuser=username --makecurrent</code> and
303
- then <emph>test that it appears on website correctly</emph>.</item>
304
- <item>If the website looks right then: <code>./tei-install.sh --package=TEIP5
305
- --version=X.X.X --sfuser=username --upload</code> and then move on to the next
306
- step.</item>
307
- </list>
308
- In each of these steps, replace the Xs with your release version. Supply your
309
- SourceForge user name, and type your SourceForge password when prompted. By default, the
310
- script will pull the release package from the first Jenkins server, but you can supply
311
- the URL of the other server if necessary with the --Jenkins parameter, e.g.
312
- --Jenkins=http://jenkins2.tei-c.org/. Make sure the script completes successfully each time
313
- changing the final parameter from --install, to --makecurrent, and then --upload. </item>
314
-
315
- <item><hi rend="bold">Repeat the steps above for the Stylesheets</hi>, remembering that the version number is the Stylesheets version, which will be different from
316
- the Guidelines version:
317
- <lb/><code>./tei-install.sh --package=Stylesheets
318
- --version=X.X.X --sfuser=username --install</code>
319
- <lb/><code>./tei-install.sh --package=Stylesheets
320
- --version=X.X.X --sfuser=username --makecurrent</code>
321
- <lb/><code>./tei-install.sh --package=Stylesheets
322
- --version=X.X.X --sfuser=username --upload</code>
323
- <lb/>
324
- </item>
325
-
326
- <item><hi rend="bold">Check the TEI website and all downloadable files are displaying the
327
- correct version</hi><lb/> Everything should now be done, so go to <ref
328
- target="https://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html">the newly
329
- released version on the TEI site</ref> and browse the Guidelines. Check that your
330
- version number is displayed in the footer of the page, and check that at least one
331
- change made since the last release is being reflected online. </item>
332
-
333
- <item><hi rend="bold">Update <ref target="https://roma.tei-c.org/">Roma</ref>,
334
- <ref target="https://romabeta.tei-c.org/">Romabeta</ref>, and <ref target="https://oxgarage.tei-c.org/">OxGarage</ref></hi>
335
- <lb/>Change to the directory <code>~/repos/infrastructure/humanum</code> and issue the script
336
- <code>docker-update.sh</code> for every service, i.e.
337
- <list>
338
- <item><code># docker-update.sh roma</code></item>
339
- <item><code># docker-update.sh romabeta</code></item>
340
- <item><code># docker-update.sh oxgarage</code></item>
341
- </list>
342
- NB: Every invocation might take some time but each should succesfully finish with the notification
343
- "Creating $CONTAINER$ ... done"
344
- </item>
345
-
346
- <item>
347
- <hi rend="bold">Make your release the default downloadable version from
348
- Sourceforge</hi><lb/> Go to the SourceForge site (<ref
349
- target="https://sourceforge.net/projects/tei/files/TEI-P5-all/">https://sourceforge.net/projects/tei/files/TEI-P5-all/</ref>),
350
- log in, and click the information button on your new release. Make it the default download for all
351
- operating systems. Now make sure that the main Download button links to your package. </item>
352
-
353
- <item>
354
- <hi rend="bold">Update tags on GitHub</hi><lb/> Every time a new release is made, a
355
- "tag" is created consisting of a pointer to the state of the P5 tree at release time.
356
- You can do this from the command line on your own computer. Before moving forward, be
357
- sure to do a git pull and update your released branch. Then, still in the released
358
- branch, do:<lb/>
359
- <code>git tag -a P5_Release_X.X.X -m "Release X.X.X of the TEI Guidelines."</code><lb/>
360
- where X.X.X is your new release. Then<lb/>
361
- <code>git push origin P5_Release_X.X.X</code>
362
- </item>
363
-
364
- <item><hi rend="bold">Make a Release on GitHub</hi><lb/> Go to the TEI Tags page at <ref
365
- target="https://github.com/TEIC/TEI/tags">https://github.com/TEIC/TEI/tags</ref> on GitHub. You should
366
- see the tag you just pushed there. Click on it and then click on "Edit Release". Add a link to the release notes README, which should be at
367
- https://www.tei-c.org/release/doc/tei-p5-doc/readme-X.X.X.html, into the text box. Add a copy of the zipped
368
- release by downloading it from <ref
369
- target="https://jenkins.tei-c.org/job/TEIP5/lastSuccessfulBuild/artifact/P5/"
370
- >https://jenkins.tei-c.org/job/TEIP5/lastSuccessfulBuild/artifact/P5/</ref> and then uploading it to the release page. </item>
371
-
372
- <item><hi rend="bold">Close/Add GitHub Milestones</hi><lb/> Go to the Milestones page of both the
373
- <ref target="https://github.com/TEIC/Stylesheets/milestones">Stylesheets</ref> and the
374
- <ref target="https://github.com/TEIC/TEI/milestones">Guidelines</ref> repo. Add new Milestones by
375
- incrementing the minor version number part and move all open issues from the current Milestone to the new one.
376
- (If Council already decided on the next release date (unlikely) you can add the date to the new Milestone. Otherwise leave empty.)
377
- Finally, close the current Milestone.</item>
378
-
379
- <item><hi rend="bold">Update the Debian Package repository with the new release</hi><lb/>
380
- The TEI Debian packages are regularily created during each Jenkins build.
381
- For each release you need to update the TEI Debian repository at
382
- <ref target="http://packages.tei-c.org/deb/">http://packages.tei-c.org/deb/</ref>
383
- which can be done by simply running <code>ant</code> on the TEI server within the
384
- <code>/data/debian-packages</code> directory.
385
- (This directory is cloned from <ref target="https://github.com/TEIC/TEI-apt-repo">https://github.com/TEIC/TEI-apt-repo</ref>)
386
- <emph>Since the repository index needs to be signed, you'll need the passphrase for the GPG key.</emph>
387
- Make sure you've received it in advance!
388
- <lb/>Once the process has finished and the repo is updated, the page at <ref target="http://packages.tei-c.org/deb/">http://packages.tei-c.org/deb/</ref>
389
- should reflect the changes immediately. If not, try to restart the NGINX Docker container that serves this directory
390
- with <code>docker restart debian-packages</code>.
391
- <!--<lb/>Another caveat: <code>ant</code> fails to fetch the packages via HTTPS when
392
- running an outdated Java VM. Make sure to set the environment variable <code>JAVA_HOME</code>
393
- to some appropriate version! At present <code>export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64</code>
394
- will do.-->
395
- </item>
396
-
397
- <item><hi rend="bold">Update the list of previous releases of P5</hi>, which is found at <ref
398
- target="https://tei-c.org/guidelines/p5/#section-2">https://tei-c.org/guidelines/p5/#section-2</ref>.<lb/>
399
- If you have editing privileges on the TEI WordPress on tei-c.org, add the new release to the top of the release table. If not, ask one of the
400
- other Council members who does (currently Martina Scholger and Hugh Cayless) to make the change. </item>
401
-
402
- <item><hi rend="bold">Update the oXygen-ready distribution of TEI.</hi><lb/> This involves
403
- building the new package of oxygen-tei, and then updating the distribution file on the
404
- TEI server so that the oXygen software knows about the new release. You may request to
405
- hand this off to one of the maintainers (currently Syd Bauman, James Cummings, or Martin
406
- Holmes) to do this for you if you're not familiar with the project. <list>
407
- <item>Check that you have ant (at least version 1.8) installed on your machine.</item>
408
- <item>Check that the latest versions of the TEI Stylesheets and TEI P5 packages are
409
- available for download from the SourceForge Files section, since the oxygen-tei
410
- update/upload script retrieves them from there.</item>
411
- <item>Check out or update a local copy of the source code from <ref
412
- target="https://github.com/TEIC/oxygen-tei"
413
- >https://github.com/TEIC/oxygen-tei</ref> to your local system.</item>
414
- <item>Make sure the build script knows where to find your oxygen.jar file (from the
415
- Oxygen installed on your system) by copying the file into
416
- <code>oxygen-tei/lib</code> or symlinking it.</item>
417
- <item>cd into the oxygen-tei folder (it should contain folders called "frameworks" and
418
- "jenkins").</item>
419
- <item>Run the ant build process with the "release" parameter: <lb/>
420
- <code>ant release</code><lb/> This builds the plugin using the latest stable
421
- versions of P5 and the Stylesheets, then offers to upload the result to the TEI's
422
- SourceForge repo to become a release of the TEI-maintained version of the plugin.
423
- This also creates an updated updateSite.oxygen file, by retrieving the latest
424
- updateSite.oxygen file from the tei-c.org site, and asks the user to provide the new
425
- version number before creating a new version of updateSite.oxygen. It also offers to
426
- upload that file to tei-c.org, if the user has shell access. </item>
427
- </list>
428
- </item>
429
-
430
- <item><hi rend="bold">Inform the TEI Technical Council Chair so they can announce the
431
- release</hi><lb/> Once you are sure that everything is working correctly, inform the
432
- Council Chair. They will announce the release to the TEI-L mailing list, including the
433
- text of P5/ReleaseNotes/readme-X.X.X.xml in plain text form (which can be generated
434
- using the "readme" profile for teitotxt), and place an announcement on the Text Encoding
435
- Initiative Newsfeed blog in the category of 'News'. </item>
436
- <item><hi rend="bold">Lift the freeze on committing changes to the repository</hi><lb/>
437
- Write to the TEI Council list and let them know that they can once again start
438
- committing changes to the repository.</item>
439
-
440
- <item><hi rend="bold">Increment the build number for the next release cycle</hi><lb/>
441
- Recalling how release preparation requires confirmation of version number,
442
- use your best judgment to determine the version number for the next release (in consultation with Council,
443
- if possible). TEI version numbers are based on the Unicode Consortium system (<ref
444
- target="http://www.unicode.org/versions/">http://www.unicode.org/versions/</ref>) but with the first
445
- digit for major changes, the second for schema-changing revisions, and the third for
446
- non-schema-changing revisions. When the first or second digit is incremented, the
447
- following digit or digits is set to zero.
448
-
449
- <!-- Revisit version control instructions at May 2020 F2F (JL, 2020-02-13) -->
450
-
451
- After the release process has been completed, the release number for both P5 and the
452
- Stylesheets needs to be updated. On the dev branch, edit the P5/VERSION file and the Stylesheets/VERSION
453
- file to the correct numbers. These files contain nothing except the bare version number.
454
- It should be incremented appropriately, and "a" added to the end of it, so if for example
455
- the release was number 2.8.0, you would change the number in the file to:<lb/>
456
- <code>2.9.0a</code><lb/> signifying that the versions built subsequent to the release
457
- are now in the alpha stage. </item>
458
-
459
- </list>
460
-
461
- </div>
462
-
463
- </body>
464
-
465
-
466
- </text>
467
- </TEI>
468
-