Decision time: exactly how and where will this release be released?

Martin Holmes

3 Oct 2015 3 Oct '15

11:51 p.m.

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

Show replies by date

Martin Holmes

4 Oct 4 Oct

9:16 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

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

Martin Holmes

9:20 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

Also, who wants to be "the current Stylesheets maintainer" for the purposes of the release technician instructions? Cheers, Martin On 15-10-04 12:16 PM, Martin Holmes wrote:

...

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

Hugh Cayless

9:36 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

I thought we’d decided to stick with pushing the files to SF for the near term at least? Assuming we want to stay with the tag format that came over from Sourceforge: git tag -a P5_Release_2.9.0 -m "Release 2.9.0 of the TEI Guidelines." git push origin P5_Release_2.9.0 Tagging is not painful in Git. :-) Tags are just pointers to commits. Should we stick with "P5_Release_x.x.x" as the name format? Hugh

...

On Oct 4, 2015, at 15:16 , Martin Holmes wrote:

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 -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Kevin Hawkins

10:10 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

On 10/4/15 2:36 PM, Hugh Cayless wrote:

...

I thought we’d decided to stick with pushing the files to SF for the near term at least?

I don't know what was decided, but note that if you want to maintain this, you can make it easy by configuring "GitHub release integration" on SourceForge: https://sourceforge.net/p/tei/admin/files/gh_integration --Kevin

Martin Holmes

10:17 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

On 15-10-04 01:10 PM, Kevin Hawkins wrote:

...

On 10/4/15 2:36 PM, Hugh Cayless wrote:

...
I thought we’d decided to stick with pushing the files to SF for the near term at least?

I don't know what was decided, but note that if you want to maintain this, you can make it easy by configuring "GitHub release integration" on SourceForge:

https://sourceforge.net/p/tei/admin/files/gh_integration

This looks interesting. It could be a gentle path to detaching from SourceForge. We could look at using this instead of our current rather arcane script process for the release after this one. I like the idea that the whole release process is done on GitHub, and SF just updates itself. I'm still inclined to think that there should be some downloadable packages (or at least a page of links to them) on tei-c somewhere. Cheers, Martin

Kevin Hawkins

11:22 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

On 10/4/15 3:17 PM, Martin Holmes wrote:

...

I'm still inclined to think that there should be some downloadable packages (or at least a page of links to them) on tei-c somewhere.

I'll let you all decide whether it's important to host files on www.tei-c.org. If you're content to link, then I think we just revise the text at http://www.tei-c.org/Guidelines/P5/ to point to: https://github.com/TEIC/TEI/releases --Kevin

Martin Holmes

10:14 p.m.

New subject: [tei-council] Decision time: exactly how and where will this release be released?

Hi Hugh, On 15-10-04 12:36 PM, Hugh Cayless wrote:

...

I thought we’d decided to stick with pushing the files to SF for the near term at least?

That's OK with me; I just wanted to be sure. It saves rewriting a bunch of scripts. But ultimately I don't think it's good for us to have products available all over the place; it's a bit confusing for people.

...

Assuming we want to stay with the tag format that came over from Sourceforge:

git tag -a P5_Release_2.9.0 -m "Release 2.9.0 of the TEI Guidelines." git push origin P5_Release_2.9.0

Tagging is not painful in Git. :-) Tags are just pointers to commits.

Should we stick with "P5_Release_x.x.x" as the name format?

Might as well; that means it'll fit into the list of releases on SourceForge and the old tags in SVN. If and when we remove SourceForge completely from the equation, we can revisit all of this if we like. Cheers, Martin

...

Hugh

...
On Oct 4, 2015, at 15:16 , Martin Holmes wrote:

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 -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

3329

Age (days ago)

3330

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Hugh Cayless
Kevin Hawkins
Martin Holmes