Hi Lou, I've just updated my Oxygen 16.1 to DEVELOPMENT BUILD 2015-05-13-052814 of the plugin, and the PDF generation works fine for me. What errors do you see? Are you on Oxygen 16.0 or 16.1? Cheers, Martin On 15-05-14 03:58 AM, Lou Burnard wrote:

Using oxyGen 16, PDF generation for jTEI articles seems to be bust in the version which identifies itself as development buils 2015-05-13-052814

With Oxygen v17 however, IT WORKS, hoorah.

On 14/05/15 09:47, James Cummings wrote:

...

I did only basic minimal tests starting a TEI all template and a jTEI one. Everything I tried seems to work as I'd expect... This isn't exhaustive testing, but I'll let you know if anything else messes up.

-James

On 14/05/15 05:35, Martin Holmes wrote:

...

Hi all,

After some more testing with Ron, I've just released a new version of the Oxygen plugin, incorporating the latest Stylesheets release (7.35.0) and some changes to the plugin codebase that we had had to back out of before Oxygen 17 was released because they depended on Stylesheets changes which hadn't been released at that point. If you're subscribed to this version of the plugin, please let me know if you see any problems.

One of the confusing issues I'll talk about when I do my little show-and-tell on the Oxygen plugin in Michigan will be version numbers. Right now, the plugin filename is derived from the P5 and Stylesheets versions incorporated in it:

teioxygen-2.8.0-7.35.0.zip = P5 2.8.0 and Stylesheets 7.35.0.

However, there also has to be a true version number for the plugin, which is inserted into the updateSite.oxygen XML file that handles the plugin updates for users. Oxygen's system only allows a version number consisting of three dotted digits:

1.2.3

Our practice up to now has been to name the plugin release after the P5 release on which it's based, so this would be:

2.8.0

but because the last one was already 2.8.0, I've had to increment it:

2.8.1

If we now go ahead and release a minor P5 update, which would be 2.8.1, we would confusingly have to increment the plugin version number to 2.8.2.

So I'd like to suggest that we detach the plugin versioning count entirely from the P5 version, and simply increment it independently; but with the second and third digits representing collapsed versions of the P5 and Stylesheets versions on which it's based:

3.280.7350

This would mean that we could have meaningful plugin version numbers simply incrementing in position 1, and still record the versions of P5 and the Stylesheets on which they're based.

Any see any problem with this? We could make the change at the same time that we switch the file naming from teioxygen to oxygen-tei, as we've discussed before.

Cheers, Martin

Thanks James. We weren't expecting any problems, but we don't have good automated tests in place yet. And to be honest, I don't really know how to write any. I've decided to try and convert the bash scripts that build the plugin to an ant task; that'll be cleaner and easier to maintain. We should be able to have a single ant task that's used for all the various build scenarios (stable-for-testing, stable-for-SF-release, stable-for-oxygen-folks, and bleeding-edge-for-testing) just controlled by a single parameter. With luck, I can have this done and working the FtF. Cheers, Martin On 15-05-14 01:47 AM, James Cummings wrote:

I did only basic minimal tests starting a TEI all template and a jTEI one. Everything I tried seems to work as I'd expect... This isn't exhaustive testing, but I'll let you know if anything else messes up.

-James

On 14/05/15 05:35, Martin Holmes wrote:

...

Hi all,

After some more testing with Ron, I've just released a new version of the Oxygen plugin, incorporating the latest Stylesheets release (7.35.0) and some changes to the plugin codebase that we had had to back out of before Oxygen 17 was released because they depended on Stylesheets changes which hadn't been released at that point. If you're subscribed to this version of the plugin, please let me know if you see any problems.

One of the confusing issues I'll talk about when I do my little show-and-tell on the Oxygen plugin in Michigan will be version numbers. Right now, the plugin filename is derived from the P5 and Stylesheets versions incorporated in it:

teioxygen-2.8.0-7.35.0.zip = P5 2.8.0 and Stylesheets 7.35.0.

However, there also has to be a true version number for the plugin, which is inserted into the updateSite.oxygen XML file that handles the plugin updates for users. Oxygen's system only allows a version number consisting of three dotted digits:

1.2.3

Our practice up to now has been to name the plugin release after the P5 release on which it's based, so this would be:

2.8.0

but because the last one was already 2.8.0, I've had to increment it:

2.8.1

If we now go ahead and release a minor P5 update, which would be 2.8.1, we would confusingly have to increment the plugin version number to 2.8.2.

So I'd like to suggest that we detach the plugin versioning count entirely from the P5 version, and simply increment it independently; but with the second and third digits representing collapsed versions of the P5 and Stylesheets versions on which it's based:

3.280.7350

This would mean that we could have meaningful plugin version numbers simply incrementing in position 1, and still record the versions of P5 and the Stylesheets on which they're based.

Any see any problem with this? We could make the change at the same time that we switch the file naming from teioxygen to oxygen-tei, as we've discussed before.

Cheers, Martin

Hi Peter, On 15-05-14 11:20 AM, Peter Stadler wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

...

So I'd like to suggest that we detach the plugin versioning count entirely from the P5 version, and simply increment it independently; but with the second and third digits representing collapsed versions of the P5 and Stylesheets versions on which it's based:

3.280.7350

This would mean that we could have meaningful plugin version numbers simply incrementing in position 1, and still record the versions of P5 and the Stylesheets on which they're based.

Hmm, I usually expect those three digit version numbers to follow the semantic versioning approach [1]. And I guess most people will not be able to decipher something like 3.280.7350 and will be astonished when there are huge gaps between releases.

Fair point. We'll scrap that approach, then.

So I wonder if we could not detach the versioning of the plugin completely from the other version numbers?! (A README is needed anyway where the correlation with the Stylesheets and the TEI source is documented)

A readme wouldn't be helpful, because most people update the plugin in the Oxygen interface, but there is a block of information in the updateSite.oxygen file which can be used to provide extra information. In the stable release, that info has been static up to now, but in the bleeding-edge build I'm manipulating it to add version info, so I could do the same in the stable build. So, if we're going with x.y.z versioning for the plugin alone, we need to decide how to increment; and anyone creating a release will have to increment it manually and provide the information to the build script. We could say something like this: MAJOR version changes whenever a new P5 comes out; MINOR version changes whenever a new Stylesheets version comes out but P5 has not changed; THIRD version number changes when only the plugin codebase changes, but P5 and the Stylesheets remain the same. Does that make sense? Cheers, Martin

Best Peter

[1] http://semver.org/ -----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJVVOdtAAoJEJclm6G69Xq2nCwH/RiG/LzrXdKVT7QiEkm1RCrl CsJ/S48yycVtiO68eGTtFeMPg3wt8eJm1P04ODGk2Yz8ANMf6zrfrdt/3yTBgVaQ TYNcp087sLZlbOCzB1XEhrmq77Qh1rCuiGT7yFzbwi3ylzkNOoUrw0BU5Mw7NU2D aEmCGT7TsFnPm4KW55EO9Y4ROwmVeFhBXBGuCLIoIPPjsqwFxBeDFNbqaaRmom0A Q+M9d1Dnza6jN+8zPRjeT+JTEDwYckbyLG9R4gu0xVpH64KwhvXJczpezcaFhT5e JKI6+4cNZwySZd4JNUNNUCq1tl00YekGiyo2vG2iSng6oRmLbHQX0V4O8vCmXLA= =qGjN -----END PGP SIGNATURE-----

Yes, that's what I would suggest, too. When we switch names, start with 1.0.0?

...

MAJOR version changes whenever a new P5 comes out;

MINOR version changes whenever a new Stylesheets version comes out but P5 has not changed;

THIRD version number changes when only the plugin codebase changes, but P5 and the Stylesheets remain the same.

Does that make sense?

That makes perfect sense to me! Others?

I think we planned to start with 3.0.0. But for today, I just released with the normal versioning approach, so we're at 2.8.2 right now. We are going to make a change to the folder and filenaming (teioxygen -> oxygen-tei, to reflect the actual project name and disambiguate from the teioxygen debian package), so I think we'll do all those things at the same time. I'm thinking that when I do my how-it-works-and-how-to-build-it show-and-tell, we could actually do a live build-and-release in which these changes are made, with everyone watching. Today's run of the ant script revealed a couple of minor things I need to fix, but one of them really is dependent on the file name change, because I wrote the script on the assumption that would be changing. Cheers, Martin On 15-05-26 01:44 PM, Hugh Cayless wrote:

We’ll have to start above 2.8.0, won’t we?

...

On May 26, 2015, at 16:40 , Syd Bauman wrote:

Yes, that's what I would suggest, too. When we switch names, start with 1.0.0?

...

...

MAJOR version changes whenever a new P5 comes out;

MINOR version changes whenever a new Stylesheets version comes out but P5 has not changed;

THIRD version number changes when only the plugin codebase changes, but P5 and the Stylesheets remain the same.

Does that make sense?

That makes perfect sense to me! Others? -- 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

We can't start with a version below what's currently installed in people's Oxygens, I don't think, otherwise it won't show as an update. Cheers, Martin On 15-05-26 02:22 PM, Syd Bauman wrote:

HC> We’ll have to start above 2.8.0, won’t we?

No, I think the point is to start below to effectively say "this is new and different", thus justifying the new naming and numbering.

MH> I think we planned to start with 3.0.0.

Well, I'd prefer 1.0.0, but as long as it's not 2.9.0 or some such silliness, it will do.