I think users who want to stay with stability of a known release would just not update it, right? This happened before and we continued to support oxygen-tei. If we release a version of the plugin that only works with 17.1+ is there a way in the updateSite file to indicate that? i.e. your oXygen won't download it if you are still running version 15? Or is there a way to have the framework and new TEI but not include anything that breaks old versions? The general reason people like that we produce this framework is that they can stay with $outDatedOXygen and get $newTEITags. If we don't release this, then we'd be forcing those people to update their oXygen in order to get new TEI... right? Or am I misunderstanding. I don't want to put those users at a disadvantage (since mostly these are slow-moving institution-based users whose institutions only upgrade their provided oXygen every few versions). I think we should examine the options more closely and not make a snap decision. Maybe we could ask the oXygen folks about it since they are here at #TEI2015? -James On 30/10/15 11:11, Lou Burnard wrote:

I agree with Martin's recommendation. Wonderful though it is, oXygen and the oXygen folks are both, it doesn't look right for the TEI to be doing their job of keeping their customers up to date. After all, there may well be oXygen users who'd prefer the stability of known release.

On 30/10/15 09:32, Martin Holmes wrote:

...

We're faced with a rather difficult decision with regard to the oxygen-tei plugin.

The Oxygen guys have introduced a lot of new features, especially relating to CSS usage in Author mode (as far as I understand it), and they've made a point of using jTEI as one of their examples. However, their new stuff only works on Oxygen 17.1. They've put it in a branch on oxygen-tei:

https://github.com/TEIC/oxygen-tei/tree/update_oxygen_17_1

Our plugin currently works on versions going back to 15.2. If we merge these exciting new changes, then people using older versions of Oxygen will suddenly get an update that breaks or won't install (I don't know exactly what will happen). However, if we don't update, we'll be in the rather odd situation that Oxygen's release will always be more advanced than our version of our plugin, which makes our plugin sort of pointless, since the main reason for it is to exist is to enable users to get a more up-to-the-minute version of the plugin.

I'm tempted to say that it might be time to retire our "official" TEI release of the plugin entirely. We could offer a bleeding-edge preview release of the plugin, based on our dev branches, which we would us for testing and would encourage savvy users with a need to get the absolute latest-and-greatest to install; but otherwise we would just rely on Oxygen's steady release cycle to keep the majority of our users up to date. That would mean a brief lag between the time that we do a major release and Oxygen does, when users of Oxygen would have no easy way to get the latest-and-greatest P5 and Stylesheets. But it would make our lives simpler.

Cheers, Martin

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

We've let this discussion drop without reaching a consensus, and I don't think we can afford to do that. To summarize: Lou and I think it might be time to drop the TEI plugin; Peter and James think the plugin ought to take on a new role, which is providing support for updating P5 and the Stylesheets in older versions of Oxygen. I think the latter would be noble but very difficult to manage. Cheers, Martin On 15-10-30 04:42 AM, Martin Holmes wrote:

Hi James,

I did talk to George and Alex about this. Your suggestion (and Peter's) that our role should be to maintain support for older versions is a bit problematic because we are also taking advantage of newer features to enhance our plugin; and the Oxygen guys are contributing to our framework too. We're basically talking about having two distinct development trees which will progressively diverge. And there's no easy way to choose which versions we intend to support.

Cheers, Martin

On 2015-10-30 12:25 PM, James Cummings wrote:

...

I think users who want to stay with stability of a known release would just not update it, right? This happened before and we continued to support oxygen-tei. If we release a version of the plugin that only works with 17.1+ is there a way in the updateSite file to indicate that? i.e. your oXygen won't download it if you are still running version 15? Or is there a way to have the framework and new TEI but not include anything that breaks old versions?

The general reason people like that we produce this framework is that they can stay with $outDatedOXygen and get $newTEITags. If we don't release this, then we'd be forcing those people to update their oXygen in order to get new TEI... right? Or am I misunderstanding. I don't want to put those users at a disadvantage (since mostly these are slow-moving institution-based users whose institutions only upgrade their provided oXygen every few versions).

I think we should examine the options more closely and not make a snap decision.

Maybe we could ask the oXygen folks about it since they are here at #TEI2015?

-James

On 30/10/15 11:11, Lou Burnard wrote:

...

I agree with Martin's recommendation. Wonderful though it is, oXygen and the oXygen folks are both, it doesn't look right for the TEI to be doing their job of keeping their customers up to date. After all, there may well be oXygen users who'd prefer the stability of known release.

On 30/10/15 09:32, Martin Holmes wrote:

...

We're faced with a rather difficult decision with regard to the oxygen-tei plugin.

The Oxygen guys have introduced a lot of new features, especially relating to CSS usage in Author mode (as far as I understand it), and they've made a point of using jTEI as one of their examples. However, their new stuff only works on Oxygen 17.1. They've put it in a branch on oxygen-tei:

https://github.com/TEIC/oxygen-tei/tree/update_oxygen_17_1

Our plugin currently works on versions going back to 15.2. If we merge these exciting new changes, then people using older versions of Oxygen will suddenly get an update that breaks or won't install (I don't know exactly what will happen). However, if we don't update, we'll be in the rather odd situation that Oxygen's release will always be more advanced than our version of our plugin, which makes our plugin sort of pointless, since the main reason for it is to exist is to enable users to get a more up-to-the-minute version of the plugin.

I'm tempted to say that it might be time to retire our "official" TEI release of the plugin entirely. We could offer a bleeding-edge preview release of the plugin, based on our dev branches, which we would us for testing and would encourage savvy users with a need to get the absolute latest-and-greatest to install; but otherwise we would just rely on Oxygen's steady release cycle to keep the majority of our users up to date. That would mean a brief lag between the time that we do a major release and Oxygen does, when users of Oxygen would have no easy way to get the latest-and-greatest P5 and Stylesheets. But it would make our lives simpler.

Cheers, Martin

Hi Peter, Either scenario (one update file, or many) would be complicated for users, I would think. We'll have to test this, though. Who has an old version of Oxygen installed? Cheers, Martin On 15-11-10 12:37 AM, Peter Stadler wrote:

I wonder if it would be so difficult? I’d imagine having several branches, i.e „14+“, „15+“ which would only be updated with the latest TEI schemas and stylesheets. The (new) dev branch would be the bleeding edge (as usual) with all updates from the oxygen people and from us. Creating the „14+“ etc. branch would only need to copy the old oXygen jars from a past release over the new ones (I hope).

The thing I’m unsure about is whether we need different update locations for every branch or if could all be served from one descriptor file?

Best Peter

...

Am 09.11.2015 um 23:21 schrieb Martin Holmes :

We've let this discussion drop without reaching a consensus, and I don't think we can afford to do that. To summarize: Lou and I think it might be time to drop the TEI plugin; Peter and James think the plugin ought to take on a new role, which is providing support for updating P5 and the Stylesheets in older versions of Oxygen. I think the latter would be noble but very difficult to manage.

Cheers, Martin

On 15-10-30 04:42 AM, Martin Holmes wrote:

...

Hi James,

I did talk to George and Alex about this. Your suggestion (and Peter's) that our role should be to maintain support for older versions is a bit problematic because we are also taking advantage of newer features to enhance our plugin; and the Oxygen guys are contributing to our framework too. We're basically talking about having two distinct development trees which will progressively diverge. And there's no easy way to choose which versions we intend to support.

Cheers, Martin

On 2015-10-30 12:25 PM, James Cummings wrote:

...

I think users who want to stay with stability of a known release would just not update it, right? This happened before and we continued to support oxygen-tei. If we release a version of the plugin that only works with 17.1+ is there a way in the updateSite file to indicate that? i.e. your oXygen won't download it if you are still running version 15? Or is there a way to have the framework and new TEI but not include anything that breaks old versions?

The general reason people like that we produce this framework is that they can stay with $outDatedOXygen and get $newTEITags. If we don't release this, then we'd be forcing those people to update their oXygen in order to get new TEI... right? Or am I misunderstanding. I don't want to put those users at a disadvantage (since mostly these are slow-moving institution-based users whose institutions only upgrade their provided oXygen every few versions).

I think we should examine the options more closely and not make a snap decision.

Maybe we could ask the oXygen folks about it since they are here at #TEI2015?

-James

On 30/10/15 11:11, Lou Burnard wrote:

...

I agree with Martin's recommendation. Wonderful though it is, oXygen and the oXygen folks are both, it doesn't look right for the TEI to be doing their job of keeping their customers up to date. After all, there may well be oXygen users who'd prefer the stability of known release.

On 30/10/15 09:32, Martin Holmes wrote:

...

We're faced with a rather difficult decision with regard to the oxygen-tei plugin.

The Oxygen guys have introduced a lot of new features, especially relating to CSS usage in Author mode (as far as I understand it), and they've made a point of using jTEI as one of their examples. However, their new stuff only works on Oxygen 17.1. They've put it in a branch on oxygen-tei:

https://github.com/TEIC/oxygen-tei/tree/update_oxygen_17_1

Our plugin currently works on versions going back to 15.2. If we

...

...

...

merge these exciting new changes, then people using older versions of Oxygen will suddenly get an update that breaks or won't install (I don't know exactly what will happen). However, if we don't update, we'll be in the rather odd situation that Oxygen's release will always be more advanced than our version of our plugin, which makes our plugin sort of pointless, since the main reason for it is to exist is to enable users to get a more up-to-the-minute version of the plugin.

I'm tempted to say that it might be time to retire our "official" TEI release of the plugin entirely. We could offer a bleeding-edge preview release of the plugin, based on our dev branches, which we would us for testing and would encourage savvy users with a need to get the absolute latest-and-greatest to install; but otherwise we would just rely on Oxygen's steady release cycle to keep the majority of our users up to date. That would mean a brief lag between the time that we do a major release and Oxygen does, when users of Oxygen would have no easy way to get the latest-and-greatest P5 and Stylesheets. But it would make our lives simpler.

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

Hi James, On 15-11-10 07:54 AM, James Cummings wrote:

Hi Martin,

I don't think you summarised my position accurately. I don't really mind but thought I should clarify.

Apologies.

Thinking about this, we encountered it before (around version 14?) and we just kept releasing up to date packages. i.e. I believe our current package does not work with earlier versions of oXygen.

It works with 15.2 and above. Or at least, we claim it does. :-) We have no testing for that in place.

I see three options:

1) We continue to release an oXygen framework package for our users, and it keeps pace with oXygen. Users of older versions of oXygen either update the schemas and stylesheets in their old TEI framework manually (using documentation we might provide) or they don't get new TEI goodness. 2) We do some hybrid solution where we create framework packages for older versions of oXygen as well as more recent ones. 3) We discontinue creation of the TEI oXygen framework, and just provide information on manually updating. 4) Something else.

Of these option 1 is my preferred one.

My question then is: are we really doing much good? Oxygen releases about twice a year, and so do we; there will be periods of two to three months when we're ahead of Oxygen, but not much more than that. If our objective is to support people who absolutely must have the bleeding edge, then I think our bleeding edge plugin is actually more useful; it lets people test development versions of P5 and the Stylesheets, and in testing, they help us. If we promote it as exactly that (and provide instructions for switching back to the main framework distributed with Oxygen, I think we'd be providing something interesting and useful all round.

We don't support old versions, except through documentation, and keep pace with the new one for the benefits it gives our user community and use any new features or functions we want. People have informally told me (usually thanking me for the blog post about it) that the auto-update of the TEI framework is the only reason they stay current with TEI developments.

Except that in order to do that, they would have to keep updating their Oxygen; and if they do that, they get a relatively recent one anyway, surely?

I'm currently using oXygen 16, 17, and 17.1 depending on what computer I'm on. I might have a laptop somewhere with an even older version if you want me to test something. (Side note: I've just negotiated and got oxford's site license for oXygen to be supported by our licensing people, rather than Sebastian ad-hoc paying for it out of one budget or the other. So we'll be using it until Summer 2017 ;-) )

If you can keep your Oxygen 16 around, that would be a good test case. The next question would be: what do we test, and how do we test it? Cheers, Martin

-James

On 10/11/15 13:42, Martin Holmes wrote:

...

Hi Peter,

Either scenario (one update file, or many) would be complicated for users, I would think. We'll have to test this, though. Who has an old version of Oxygen installed?

Cheers, Martin

On 15-11-10 12:37 AM, Peter Stadler wrote:

...

I wonder if it would be so difficult? I’d imagine having several branches, i.e „14+“, „15+“ which would only be updated with the latest TEI schemas and stylesheets. The (new) dev branch would be the bleeding edge (as usual) with all updates from the oxygen people and from us. Creating the „14+“ etc. branch would only need to copy the old oXygen jars from a past release over the new ones (I hope).

The thing I’m unsure about is whether we need different update locations for every branch or if could all be served from one descriptor file?

Best Peter

...

Am 09.11.2015 um 23:21 schrieb Martin Holmes :

We've let this discussion drop without reaching a consensus, and I don't think we can afford to do that. To summarize: Lou and I think it might be time to drop the TEI plugin; Peter and James think the plugin ought to take on a new role, which is providing support for updating P5 and the Stylesheets in older versions of Oxygen. I think the latter would be noble but very difficult to manage.

Cheers, Martin

On 15-10-30 04:42 AM, Martin Holmes wrote:

...

Hi James,

I did talk to George and Alex about this. Your suggestion (and Peter's) that our role should be to maintain support for older versions is a bit problematic because we are also taking advantage of newer features to enhance our plugin; and the Oxygen guys are contributing to our framework too. We're basically talking about having two distinct development trees which will progressively diverge. And there's no easy way to choose which versions we intend to support.

Cheers, Martin

On 2015-10-30 12:25 PM, James Cummings wrote:

...

I think users who want to stay with stability of a known release would just not update it, right? This happened before and we continued to support oxygen-tei. If we release a version of the plugin that only works with 17.1+ is there a way in the updateSite file to indicate that? i.e. your oXygen won't download it if you are still running version 15? Or is there a way to have the framework and new TEI but not include anything that breaks old versions?

The general reason people like that we produce this framework is that they can stay with $outDatedOXygen and get $newTEITags. If we don't release this, then we'd be forcing those people to update their oXygen in order to get new TEI... right? Or am I misunderstanding. I don't want to put those users at a disadvantage (since mostly these are slow-moving institution-based users whose institutions only upgrade their provided oXygen every few versions).

I think we should examine the options more closely and not make a snap decision.

Maybe we could ask the oXygen folks about it since they are here at #TEI2015?

-James

On 30/10/15 11:11, Lou Burnard wrote: > I agree with Martin's recommendation. Wonderful though it is, > oXygen and the oXygen folks are both, it doesn't look right > for the TEI to be doing their job of keeping their customers > up to date. After all, there may well be oXygen users who'd > prefer the stability of known release. > > > On 30/10/15 09:32, Martin Holmes wrote: >> We're faced with a rather difficult decision with regard to >> the oxygen-tei plugin. >> >> The Oxygen guys have introduced a lot of new features, >> especially relating to CSS usage in Author mode (as far as >> I understand it), and they've made a point of using jTEI as >> one of their examples. However, their new stuff only works >> on Oxygen 17.1. They've put it in a branch on oxygen-tei: >> >> https://github.com/TEIC/oxygen-tei/tree/update_oxygen_17_1 >> >> >>

Our plugin currently works on versions going back to 15.2. If we

...

>> merge these exciting new changes, then people using older >> versions of Oxygen will suddenly get an update that breaks >> or won't install (I don't know exactly what will happen). >> However, if we don't update, we'll be in the rather odd >> situation that Oxygen's release will always be more >> advanced than our version of our plugin, which makes our >> plugin sort of pointless, since the main reason for it is >> to exist is to enable users to get a more up-to-the-minute >> version of the plugin. >> >> I'm tempted to say that it might be time to retire our >> "official" TEI release of the plugin entirely. We could >> offer a bleeding-edge preview release of the plugin, based >> on our dev branches, which we would us for testing and >> would encourage savvy users with a need to get the absolute >> latest-and-greatest to install; but otherwise we would just >> rely on Oxygen's steady release cycle to keep the majority >> of our users up to date. That would mean a brief lag >> between the time that we do a major release and Oxygen >> does, when users of Oxygen would have no easy way to get >> the latest-and-greatest P5 and Stylesheets. But it would >> make our lives simpler. >> >> 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

Hi James, On 15-11-10 09:26 AM, James Cummings wrote:

On 10/11/15 17:04, Martin Holmes wrote:

...

It works with 15.2 and above. Or at least, we claim it does. :-) We have no testing for that in place.

Precisely my point... I know people on version 14.

...

My question then is: are we really doing much good? Oxygen releases about twice a year, and so do we; there will be periods of two to three months when we're ahead of Oxygen, but not much more than that.

But in order to benefit from that, then users must purchase a new version of oXygen. What I'm suggesting allows users to _stay_ with their current version of oXygen as long as oXygen don't make another backwards non-compatible change. i.e. a user now reluctantly convinces his department to allow him to update to 17.1 and then can stay on 17.1 but get new versions of the TEI and Stylesheets until they make some similar change in a few years.

I'd want to get some confirmation from Oxygen that they won't make such a major change any time soon, in that case; and they seem to be in a heavy development cycle for Author mode right now, so I wouldn't be surprised if the changes don't come thick and fast. So that's the first thing to find out: if we upset all our existing users by saying "from here on, you need Oxygen 17.1", will we upset them all again when the next Oxygen version comes out?

The users I'm thinking about are not the bleeding edge, but those who can figure out the instructions to set up the auto-update of the framework, but otherwise would have to buy a new version of oXygen to get a new TEI in the way they use it.

We used to provide instructions for rolling out a new P5 and Stylesheets directly into the framework directory; perhaps that would be a better option if our objective is to keep users up to date?

I think if we stop offering this then there will be a larger number of users who stick with significantly outdated versions of the TEI.

That's already the case, of course.

...

If our objective is to support people who absolutely must have the bleeding edge, then I think our bleeding edge plugin is actually more useful; it lets people test development versions of P5 and the Stylesheets, and in testing, they help us. If we promote it as exactly that (and provide instructions for switching back to the main framework distributed with Oxygen, I think we'd be providing something interesting and useful all round.

I'm not talking about the bleeding edge.

...

Except that in order to do that, they would have to keep updating their Oxygen; and if they do that, they get a relatively recent one anyway, surely?

Yes, but then won't have money to continually update again and again. So if we can offer them a way to update their framework without updating their oXygen, then it is beneficial.

So what we do is: - One final release of the old codebase to support old versions of Oxygen. This comes with a warning that future updates will be incompatible with Oxygen pre-17.1. - A subsequent release which is based on the 17.1 codebase, which will be rejected (presumably) by older versions of Oxygen, but will install on 17.1 and above. - All future releases based on the 17.1 codebase; users who don't have 17.1 or above can no longer update their P5 or Stylesheets (except manually).

...

If you can keep your Oxygen 16 around, that would be a good test case. The next question would be: what do we test, and how do we test it?

Actually, thinking about it, don't we have these all packaged up as debian packages? Or did we only keep the most recent ones?

I'm not sure I understand the connection between the debs and the plugin. Cheers, Martin

-James

On 15-11-10 12:37 PM, James Cummings wrote:

On 10/11/15 17:34, Martin Holmes wrote:

...

I'm not sure I understand the connection between the debs and the plugin.

Ah, I see. I think we might have decided to discontinue the tei-oxygen deb at the meeting, but we could always revisit that.

I was only suggesting that we might be able to install the tei-oxygen debian package for earlier versions.

Checking, it seems though we only have the last two issued, 15.2 and 16.2 which means the last time we did a tei-oxygen debian package release was 20 July 2014.

I suspect that given the plugin and the steady rate of Oxygen releases, Sebastian didn't see much point in it. Cheers, Martin

-James

I’m with Martin that I don’t find it worth the effort to support current oXygen versions where the difference between our release cycle and the oXygen release cycle is rather small. I would find it worth the effort to support older versions, as there are people out there with outdated oXygen versions (I’ve seen version 13 at our workshop in Lyon) and it’s much easier for them to install the plugin *once* rather than fiddling with the internal schemas every time we make a release (which they won’t do). Relying on the oXygen plugin not to break old installations from version 17 on is a false hope IMHO, as we saw significant changes with 14+, 15+ and 17. So my bet would be that we can expect another plugin change with the next major release 18. So, what I’m suggesting is: * copy the current master branch to a branch called „15+“. * copy the current master branch to a new branch „dev“ and merge with the „update_oxygen_17_1“ branch * create Jenkins projects for both branches * the oxygen-tei-plugin from the dev branch will receive the *bleeding edge* schemas and stylesheets from the respective *dev* branches * the oxygen-tei-plugin from the 15+ branch will receive the *stable* schemas and stylesheets from the respective *master* branches * we can easily move the current dev branch to a „17+“ branch when the oxygen people move on * we could easily(?) add more branches going back in time, supporting e.g. 14+ and 15+ What do you think? Cheers Peter

Am 10.11.2015 um 18:34 schrieb Martin Holmes :

Hi James,

On 15-11-10 09:26 AM, James Cummings wrote:

...

On 10/11/15 17:04, Martin Holmes wrote:

...

It works with 15.2 and above. Or at least, we claim it does. :-) We have no testing for that in place.

Precisely my point... I know people on version 14.

...

My question then is: are we really doing much good? Oxygen releases about twice a year, and so do we; there will be periods of two to three months when we're ahead of Oxygen, but not much more than that.

But in order to benefit from that, then users must purchase a new version of oXygen. What I'm suggesting allows users to _stay_ with their current version of oXygen as long as oXygen don't make another backwards non-compatible change. i.e. a user now reluctantly convinces his department to allow him to update to 17.1 and then can stay on 17.1 but get new versions of the TEI and Stylesheets until they make some similar change in a few years.

I'd want to get some confirmation from Oxygen that they won't make such a major change any time soon, in that case; and they seem to be in a heavy development cycle for Author mode right now, so I wouldn't be surprised if the changes don't come thick and fast. So that's the first thing to find out: if we upset all our existing users by saying "from here on, you need Oxygen 17.1", will we upset them all again when the next Oxygen version comes out?

...

The users I'm thinking about are not the bleeding edge, but those who can figure out the instructions to set up the auto-update of the framework, but otherwise would have to buy a new version of oXygen to get a new TEI in the way they use it.

We used to provide instructions for rolling out a new P5 and Stylesheets directly into the framework directory; perhaps that would be a better option if our objective is to keep users up to date?

...

I think if we stop offering this then there will be a larger number of users who stick with significantly outdated versions of the TEI.

That's already the case, of course.

...

...

If our objective is to support people who absolutely must have the bleeding edge, then I think our bleeding edge plugin is actually more useful; it lets people test development versions of P5 and the Stylesheets, and in testing, they help us. If we promote it as exactly that (and provide instructions for switching back to the main framework distributed with Oxygen, I think we'd be providing something interesting and useful all round.

I'm not talking about the bleeding edge.

...

Except that in order to do that, they would have to keep updating their Oxygen; and if they do that, they get a relatively recent one anyway, surely?

Yes, but then won't have money to continually update again and again. So if we can offer them a way to update their framework without updating their oXygen, then it is beneficial.

So what we do is:

- One final release of the old codebase to support old versions of Oxygen. This comes with a warning that future updates will be incompatible with Oxygen pre-17.1.

- A subsequent release which is based on the 17.1 codebase, which will be rejected (presumably) by older versions of Oxygen, but will install on 17.1 and above.

- All future releases based on the 17.1 codebase; users who don't have 17.1 or above can no longer update their P5 or Stylesheets (except manually).

...

...

If you can keep your Oxygen 16 around, that would be a good test case. The next question would be: what do we test, and how do we test it?

Actually, thinking about it, don't we have these all packaged up as debian packages? Or did we only keep the most recent ones?

I'm not sure I understand the connection between the debs and the plugin.

Cheers, Martin

...

-James

-- 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