Deafening silence on this so far, so I'm leaving the old push-products-to-SF stuff in place with a warning for the moment. However, one bit I think needs to be done by people with serious git-fu. Step 11 of the release process looks like this: ~~~~~~~~~~~~ 11. Update SVN tags on SourceForge Every time a new release is made, a "tag" is created consisting of a complete copy of the P5 tree at release time. You can do this from the command line on your own computer. This is how to do it: svn copy -m "Tagging the X.X.X release of P5." https://svn.code.sf.net/p/tei/code/trunk/P5 https://svn.code.sf.net/p/tei/code/tags/P5_release_X.X.X where X.X.X is your new release. Supply your SourceForge credentials if prompted; if an ssh key has been set up on SourceForge, you won't need to. ~~~~~~~~~~~ Obviously this needs to be replaced by the corresponding instructions for git/GitHub. Could one of our git mavens help here? Another important issue I want to warn everyone about: there is a copy of the P5 svn repo on tei-c.org (~private/P5) which used to be where we ran the tei-install etc. scripts to finish the release process. I've archived this ("P5" -> "P5_old"), and replaced it with a new git one: ~private/git/P5 updating the release instructions correspondingly. Note that P5 is nested one layer deeper than it used to be with SVN, because of the complexity of checking out a subtree in git. I've looked through the bash scripts and I can't see any relative paths that might cause problems due to this change in nesting, but if you're the release technician, watch out for that just in case. Cheers, Martin On 15-10-03 02:51 PM, Martin Holmes wrote:
HI all,
I've updated TCW20 (How to Edit the Guidelines) and I'm beginning work on TCW22 (Building a TEI Release). These instructions, along with a lot of our automated processes, assume that the release will be pushed up to SourceForge (therefore requiring that the release technician have shell access to the SF repo). To me this really makes no sense any more; I think we should make this release the point at which we move our products over to both GitHub (for releases from each individual repository) and tei-c.org (for a catalogue of all releases, past and present, in downloadable format). All in favour say aye, all against say why, please.
Since we haven't yet established a procedure for doing a release under the new conditions, I don't propose to make it up and describe it ahead of time. I suggest we go through the process, led this time by those with the most familiarity with our past and present systems rather than by a novice release technician, and then construct the documentation after the event, when we know what we ended up doing and what worked. Again, anyone think this is wrong?
For the moment, then, what I propose to do with TCW22 is to comment out any references to SF, update any references to svn to refer to git, and leave the document in an incomplete state which retains only the bits that still make sense.
Cheers, Martin