Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[upTeX] リリース方針、正式版の管理方法など #44

Closed
t-tk opened this issue Jan 21, 2018 · 24 comments
Closed

[upTeX] リリース方針、正式版の管理方法など #44

t-tk opened this issue Jan 21, 2018 · 24 comments

Comments

@t-tk
Copy link
Collaborator

t-tk commented Jan 21, 2018

upTeX 関連ソフトのバージョン管理、リリースなどについて整理し、合意しておきたいと思います。

かつては私のサイトでリリースしたものが唯一でした。その後私の出したものを texjporg でまとめて CTAN 登録のような流れになりました。今後 uptex-base や uptex-fonts などでこちらで作業したものをリリースすることが増えていくことになると思います。その方向は良いのですが、どれが正式なのか、どれが開発途中なのか分かりにくく混乱しています。
開発速度を落とさず、かつ、statusの把握が明瞭になり、かつ、開発内容の合意が作りやすいような方法を作りたいです。デフォルトの動作を変えるような場合には、リリースのタイミングのコントロールも必要と思います。
以下、私案です。

ソースの管理について
Build の下

  • Build/source/texk/web2c/uptexdir : TeX Live svn がマスター。開発は https://github.com/texjporg/tex-jp-build で行う。開発途中の作業はmasterと別ブランチで行い、master へのマージとTeX Live svnへのマージを同期させる。
  • Build/source/texk/makejvf : TeX Live svn がマスター。開発は https://github.com/texjporg/tex-jp-build で行う。開発途中の作業はmasterと別ブランチで行い、master へのマージとTeX Live svnへのマージを同期させる。
    Buildの下は TeX Live の各年のリリースを区切りに開発を進める。

Master の下

  • uptex-base: CTANがマスター(リリース版)、開発は https://github.com/texjporg/uptex-base で行う。開発途中のものはmasterと別ブランチで行い、master へのマージと CTAN 登録を同期させる。
  • uptex-fonts: CTANがマスター(リリース版)、開発は https://github.com/texjporg/uptex-fonts で行う。開発途中のものはmasterと別ブランチで行い、master へのマージと CTAN 登録を同期させる。
  • uplatex: CTANがマスター(リリース版)、開発は https://github.com/texjporg/uplatex で行う。開発途中のものはmasterと別ブランチで行い、master へのマージと CTAN 登録を同期させる。

バージョン番号について
upTeX のバージョン番号は、かつては、uptexdirのものだけでなくmakejvf, uptex-base, uptex-fonts, uplatex も含めた全てについてまとめて付けられていました。現状 1.22 になっています。
すでに makejvf と uplatex は、リリースのタイミングが upTeXとは切り離されています。
uptex-base と uptex-fonts については、そろそろ切り離すべきかあくまで uptexdir と同期させるべきか迷いがあります。uptex-base の中のドキュメント類や、ukinsoku.tex のように基本的な動作に影響がある場合に uptexdir と同期させたい・同期させなければならない場合もあり、そういう場合のリリース手順も合意しておきたいです。

\ptexversion, \ptexminorversion, \ptexrevision, \uptexversion, \uptexminorversion, \uptexrevision などの導入を推進していただきありがとうございます。
仕様は、結局どうなったのでしょうか?
反対意見は無いのですが、理解できていません。一度解説をお願いしたいです。

@aminophen
Copy link
Member

aminophen commented Jan 21, 2018

仕様は、結局どうなったのでしょうか?

r46399 で導入したものは,以下のようになっています。

  • \ptexversion --> 3(内部整数)
  • \ptexminorversion --> 8(内部整数)
  • \ptexrevision --> ".0"(文字列)
  • \epTeXversion --> 180121(内部整数)
  • \uptexversion --> 1(内部整数)
  • \uptexrevision--> ".22"(文字列)
$ ptex --version
pTeX 3.14159265-p3.8.0 (utf8.euc) (TeX Live 2018/dev)
$ uptex --version
upTeX 3.14159265-p3.8.0-u1.22 (utf8.uptex) (TeX Live 2018/dev)
$ eptex --version
e-pTeX 3.14159265-p3.8.0-180121-2.6 (utf8.euc) (TeX Live 2018/dev)
$ euptex --version
e-upTeX 3.14159265-p3.8.0-u1.22-180121-2.6 (utf8.uptex) (TeX Live 2018/dev)

@t-tk
Copy link
Collaborator Author

t-tk commented Jan 21, 2018

aminophen様、ありがとうございます。
もう一つ。upTeX で現状やりたいと思っていることは

これらは、仕様と実装もほぼ固まって、もう少しテストして整理すればリリース出来るところまで来ていると思います。ドキュメントやsampleの更新もしておきたいです。
まとめて upTeX 1.23 としようか、あるいは、uptex-fonts の更新は upTeX の更新とは別物と考えるか?
リリースの手順、タイミングはどうしましょうか。

@h-kitagawa
Copy link
Member

r46399 では \ptexrevision --> ".0"(文字列)です.
\eTeXrevision,\uptexrevision, \Omegarevision に合わせ.途中でドットを加えました.

@aminophen
Copy link
Member

r46399 では \ptexrevision --> ".0"(文字列)です.

ありがとうございます,上のコメントも修正しました。

@aminophen
Copy link
Member

開発速度を落とさず、かつ、statusの把握が明瞭になり、かつ、開発内容の合意が作りやすいような方法を作りたいです。デフォルトの動作を変えるような場合には、リリースのタイミングのコントロールも必要と思います。

同意します。

ソースの管理について
Build の下

大まかに同じ意見です。「Buildの下は TeX Live の各年のリリースを区切りに開発を進める。」については,正式バイナリのビルドが年一回であることから,pretest 期間(=正式ビルド直前期)には少なくとも安定させるべく,十分な余裕を持って確定させる,というイメージでしょうか。

Master の下

こちらも大まかに同じ意見です。「開発途中のものはmasterと別ブランチで行い」については私は現状あまり守れていません。(一応,非互換を発生しうる大きな変更は別ブランチを立て,明らかな typo やドキュメント増量などは master へというような運用です。)

バージョン番号について
uptex-base と uptex-fonts については、そろそろ切り離すべきかあくまで uptexdir と同期させるべきか迷いがあります。uptex-base の中のドキュメント類や、ukinsoku.tex のように基本的な動作に影響がある場合に uptexdir と同期させたい・同期させなければならない場合もあり、そういう場合のリリース手順も合意しておきたいです。

これは変更内容次第だと思いますが,「完全に同時でなければならない」ケースはそう多くないので,上にある通りの Build と Master の運用でいけそうだと思います。

例えば #43 に影響を受ける ukinsoku.tex は,更新時期がずれた場合の影響を考えると

  • uptexdir が uptex-base よりも早い場合
    • ukinsoku.tex が正常に読めず NG。
  • uptex-base が uptexdir よりも早い場合
    • 問題なし。

と思われるので,uptexdir を待たずに安全策で uptex-base を先に出して良いと思います。

逆に #8 の JFM 仕様拡張は ptex-base の jfm.pdf の更新を伴うべきですが,ptexdir が先でなければならないので,ptex-base は次年度の pretest を待ってリリースだと思います(必要に応じて別ブランチ化)。

upTeX で現状やりたいと思っていること
これらは、仕様と実装もほぼ固まって、もう少しテストして整理すればリリース出来るところまで来ていると思います。ドキュメントやsampleの更新もしておきたいです。

uptex-fonts も uptex-base と同様に考えれば,uptexdir より早いリリースで問題は起きませんから,切り離して先にリリースするのも一案だと思います。

@t-tk
Copy link
Collaborator Author

t-tk commented Jan 21, 2018

(一応,非互換を発生しうる大きな変更は別ブランチを立て,明らかな typo やドキュメント増量などは master へというような運用です。)

これでもOKです。それなら例えば、Master の下は、

  • CTANがマスター(リリース版)
  • 開発は、
    • 軽微なものは tex-jp-org の master ブランチで作業
    • 非互換の虞のある大きな変更は tex-jp-org の別ブランチで作業
    • CTANリリースの度に、masterにマージしてTAGを打つ

でどうでしょう。

uptexdir を待たずに安全策で uptex-base を先に出して良いと思います。

同意します。
今後、私は当面 uptex-base の更新を別ブランチで進めることにします。

@aminophen
Copy link
Member

あと,気になるのはトップの README.md にある

This bundle does not intend to provide the latest "upstream" sources

です。今回の方針であれば,source/texk にある README に「ptex, uptex, eptex, euptex はココが upstream である」と明記しても差し支えないと思いますが,いかがでしょうか?

@t-tk
Copy link
Collaborator Author

t-tk commented Jan 22, 2018

uptex-fonts も uptex-base と同様に考えれば,uptexdir より早いリリースで問題は起きませんから,切り離して先にリリースするのも一案だと思います。

uptex-fonts は内容が既に固まっているという認識ですのでupTeX本体と切り離して近々リリースしたいです。
こちら texjporg/uptex-fonts#3 で話題を出していたので細かい点はそちらで議論しましょう。

This bundle does not intend to provide the latest "upstream" sources

当時こういう風にした理由はいくつかありますが、

  1. dvipdfmx, dvips など、tex-jp-org がupstreamでないソースを含んでいる
  2. texjporg/tex-jp-build がどの程度受け入れてもらえるか、運用が上手く行くかどうか、未知数だった
  3. eptex は、北川さんのところが upstream??
  4. uptex は、(最終的にTeX Liveやここにマージするにしても)フォーク先 https://github.com/t-tk/tex-jp-build を開発拠点かつ upstream にしようかと考えていた。(私以外に触る方が出てこられることをあまり想定していなかった)

ptexenc, ptex はここが upstream でもよいと思いますが、どうしましょうか。

@h-kitagawa
Copy link
Member

eptex は、北川さんのところが upstream??

eptex もここが upstream としてしまって良いです.Wiki (ほとんど機能していませんが)は,過去の (TeX Live マージ前の)版や,TeX Live マージ後の eptexdir/ の更新情報を載せる場所としておこうと思います.

@aminophen
Copy link
Member

ptexenc, ptex はここが upstream でもよいと思いますが、どうしましょうか。
eptex もここが upstream としてしまって良いです.

コメントありがとうございます。

uptex は、(最終的にTeX Liveやここにマージするにしても)フォーク先 https://github.com/t-tk/tex-jp-build を開発拠点かつ upstream にしようかと考えていた。(私以外に触る方が出てこられることをあまり想定していなかった)

これまでに触ったのは,多分 ptexdir の変更 → uptexdir で追随しないとビルドが通らなかった(change file が当たらなかった)から,ではないかと思います。

dvipdfmx, dvips など、tex-jp-org がupstreamでないソースを含んでいる

例えば以下のようにするのはどうでしょう?


This bundle provides a minimum subset of TeX Live subversion repository for building binaries of Japanese TeX processing tools. This bundle also provides the latest "upstream" sources for followings: ptexenc, ptex, eptex.

Other tools and libraries (kpathsea, dvips, dvipdfmx etc.) are only for easy building/testing of an experimental environment for developers; we do not intend to provide the "upstream" sources.

@aminophen
Copy link
Member

少し脱線する気がしますが:

pTeX のマニュアルを作るプロジェクト https://github.com/texjporg/ptex-manual を進めているのですが,ついでに(?)upTeX のマニュアルも作ってはどうかと思っています。とりあえず同じ場所の uptex-manual ブランチを作って,upTeX の拡張プリミティブを簡単にリストアップしましたが,

  • そもそも必要かどうか
  • 作業場所 (upstream) はどこがいいか

はあまり考えていません。ご意見をいただけますと幸いです。

@t-tk
Copy link
Collaborator Author

t-tk commented Jan 23, 2018

ご意見ありがとうございます。
ptexenc, ptex, eptex に加えさらに makejvf の upstream はここということにしたいと思います。
uptex は、まだしばらくは私のところにさせてください。IVSや絵文字のうち合成が必要なものなど、もう少し検討したいことがあります。
mendex は成り行き上私がメンテナーになっていますが、枯れたソフトなのでこれ以上の拡張は考えにくいと思います。もし何か希望があれば何なりとどうぞ。
upmendex と dvi2tty は、私のところで続けます。

upTeX 関連で tex-jp-build 以外のものでいうと、
uplatex は、頻繁に platex への追従をこちらで進めていただいて有難く思っています。
uptex-fonts は、今までは基本的に私が出したものとほぼ同一でしたが、現在開発中のもののリリースを機にこちらを upstream としたいと思います。
uptex-base は、現状私が出したものの微修正の範囲であり、私が思いもよらぬ方向に進むこともなく、特に言うことはありません。

uptex-manual については、私主導では出来そうにないので進めていただけると有難いです。

  • そもそも必要かどうか

01uptex_doc_utf8.txt のおしまいの方に要検討事項に挙げてあったように、やるべきことだと思いつつ、「必要性は無いわけではないが優先順位は低い」ような感覚だったので手つかずでした。

  • 作業場所 (upstream) はどこがいいか

uptex の拡張部分だけを書くことにして ptex-manual と一緒のところで管理するくらいでも充分と思います。
蛇足かつ要らぬ心配ながら「マニュアルに書いてしまったのが足かせになり、将来動作変更がやりづらくなった」ということが無ければよいです。

@aminophen
Copy link
Member

また少し tex-jp-build 以外の話ですが texjporg/jsclasses#63

「\documentclass{jsreport} と \documentclass[report]{jsbook} は互換なはずなのに,otf パッケージを読み込むと相互にレイアウトが異なる」

という問題が出ています。詳細は当該 issue を参照いただきたいのですが,対処は japanese-otf(-uptex) 側で行う必要があると思っています。他にも ZR さんが,「pdflatex で \usepackage{ajmacros} すると無限ループする」という問題等に気づいていらっしゃって,

https://github.com/zr-tex8r/japanese-otf-mirror/branches

で修正案を出してくださっています。しかし現状,

  • japanese-otf の開発者 = 齋藤さん
  • japanese-otf の CTAN uploader = ノルベルトさん
  • japanese-otf-uptex の開発者,CTAN uploader = ttk さん

という状態で,どなたにご提案すればいいのか悩んでいます。

@t-tk
Copy link
Collaborator Author

t-tk commented Jan 24, 2018

「\documentclass{jsreport} と \documentclass[report]{jsbook} は互換なはずなのに,otf パッケージを読み込むと相互にレイアウトが異なる」
これは、japanese-otf-uplatex や uplatex 抜きに japanese-otf と platex で発現するものですよね?
それならば齋藤さんにパッチを送って改訂をお願いするのが原則と思います。
japanese-otf-uptex の otf.sty は、japanese-otf の otf.sty を上書きさせてもらう形を取っているので、それに sync することになります。タイムラグはどうしても発生してしまいます。

@aminophen
Copy link
Member

これは、japanese-otf-uplatex や uplatex 抜きに japanese-otf と platex で発現するものですよね?

そうです。

それならば齋藤さんにパッチを送って改訂をお願いするのが原則と思います。

ありがとうございます。パッチの内容をある程度取りまとめてからの方がお手数をかけないだろうと思い,議論だけ始めておりましたが,報告先がわからなかったので助かります。

@norbusan
Copy link
Member

えええ、まだ僕はjapanese-otfのCTAN uploaderですか。。。それは別にTeXjpに移していいと思います。昔々、日本人全くCTANにアップしていないときの足跡ですね。今そうではありません。
僕が出来ることがあれば、是非お知らせ!

@t-tk
Copy link
Collaborator Author

t-tk commented Feb 18, 2018

ここで私が行いたかった議論自体は既にまとまっていると思います。
連絡のため、upTeX-1.23 リリースまでこの Issue を継続します。

残件と手順は

  1. [uptex-base] ukinsoku.tex 更新
  2. [uptex-base] samples 更新
  3. [uptex-base] ドキュメント更新
  4. uptex-base を CTANへリリース
  5. upTeX-1.23 リリース、TeX Live svn の Buildへコミット

現状 2までほぼ完了で、作業状況は https://github.com/texjporg/uptex-base/tree/upTeX-1.23-pre です。
今月末までにリリースまで終えたいと考えています。
Latinのkcatcode規定値変更については、upTeX-1.23リリース前にTeXフォーラムでアナウンスしようと考えています。
何かお気づきの点、ご意見などありましたらお知らせください。

@aminophen
Copy link
Member

とりあえずテストしやすいように,upTeX-1.23 の uptexdir をこのリポジトリに持ってきてみました。

@t-tk さんの upstream にある uptex-devel branch のものを

$ git cherry-pick cedca2a
$ git cherry-pick 7a4fdd2
$ git cherry-pick 43f5fee
$ git cherry-pick 4395048
$ git cherry-pick 7ebcad9
$ git cherry-pick bb06ecd

としたのが uptex-1.23-dev ブランチです。しばらく動かしてみます。

@t-tk
Copy link
Collaborator Author

t-tk commented Feb 19, 2018

"[uptex-base] ドキュメント更新" はほぼ完了しました。
リリース日は仮に2月24日に設定しています。

texjporg/uptex-fonts#2 で話題になった ukinsoku.tex での設定の8bit欧文との干渉について、01uptex_doc_utf8.txt の中で以下のように書いてみました。

◇ ukinsoku.tex に関する注意事項
ukinsoku.tex で行なった禁則ペナルティに関する設定において、
UnicodeとCJK(JIS X 0213等)の文字を想定して設定されたものの中に
文字コードが 0x80..0xFF のものを含んでいる。
それらの設定は仕様上、8bit欧文の文字にも同時に作用してしまう。
8bit欧文がT1の場合について下記にまとめた。
この動作が不都合な場合は、ユーザー各位の利用状況に応じて適宜
設定を変更するようお願いする。

文字コード  Unicode      T1
 0xA1      U+00A1 (¡)   ą {\k a}
 0xAA      U+00AA (ª)   ł {\l}
 0xAB      U+00AB («)   ń {\@tabacckludge'n}
 0xB2      U+00B2 (²)   š {\v s}
 0xB3      U+00B3 (³)   ş {\c s}
 0xB7      U+00B7 (·)   ů {\r u}
 0xB9      U+00B9 (¹)   ź {\@tabacckludge'z}
 0xBA      U+00BA (º)   ž {\v z}
 0xBB      U+00BB (»)   ż {\.z}
 0xBF      U+00BF (¿)   £ {\textsterling}

@t-tk
Copy link
Collaborator Author

t-tk commented Feb 22, 2018

「upTeX-1.23リリース前にTeXフォーラムでアナウンス」は完了。

TeX Wiki > upTeX,upLaTeX > 欧文 (ギリシャ文字、キリル文字を含む) の記述も更新必要。 →最低限の更新完了(2018/02/24)
https://texwiki.texjp.org/?upTeX%2CupLaTeX#g25333bf

@t-tk
Copy link
Collaborator Author

t-tk commented Feb 24, 2018

私のサイト で upTeX-1.23 をリリースしました。
uptex-base の変更点は masterにマージしました。https://github.com/texjporg/uptex-base
次は uptex-base を CTANへリリースすることですが、今時間がないので後ほどするつもりです。

@t-tk
Copy link
Collaborator Author

t-tk commented Feb 24, 2018

先ほど uptex-base をCTANへ投稿しました。
TeX Liveへは uptex-base の更新がMasterに来たら Build の方にコミットする予定です。

@t-tk
Copy link
Collaborator Author

t-tk commented Feb 25, 2018

upTeX 1.23 の予定は全て終わりました。
TeX Live svn r46737 でコミット済み。完了です。

@t-tk t-tk closed this as completed Feb 25, 2018
@aminophen
Copy link
Member

ありがとうございます!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants