Re: [tei-council] A decision we have to take on oxygen-tei

I like this in principle, other than that I think "will receive" should be "will retrieve" (when building). In practice, I think releasing multiple versions of the plugin (how many? One for every minor Oxygen release since 14?) is going to be horribly confusing for all involved. Cheers, Martin On 15-11-10 12:50 PM, Peter Stadler wrote:

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