Yes, but my point is that in the unlikely (?) event of the bleedin-edge version being broken, I will be happy to roll back to the previous stable release until such time as it's fixed. On 04/02/15 18:52, Martin Holmes wrote:
Hi Lou,
The idea is that if you're a brave soul using the Jenkins build, there's the likelihood that once in a while it will break. When that happens, you want to be able to roll back to a previous working version of the plugin, so you can continue with your work, while you or someone else tracks down the problem and fixes it; then you can update again to the latest.
We sincerely hope that we never release a broken version of the stable build, so the ability to roll back (which isn't currently included in the stable build) is not needed; but one reason for the whole Jenkins-test-build idea is to reduce the likelihood of that considerably.
Cheers, Martin
On 15-02-04 10:33 AM, Lou Burnard wrote:
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release!
So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen>
On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
-James