Re: LyX version 2.3.0 (beta 1)

[Pavel Sanda]

Kornel Benko wrote:
> We may want to unify the output of msgmerge to possibly minimize the 
> differences in po-files.

We tried and were not capable to unify it on Uwe's box, I am not going into the 
same debate again so it's completely your call. P

Re: LyX version 2.3.0 (beta 1)

[Kornel Benko]

Am Montag, 4. September 2017 um 02:28:33, schrieb Scott Kostyshak 

> On Sun, Sep 03, 2017 at 11:11:55PM +0200, Kornel Benko wrote:
> > Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda 
> > 
> > > Scott Kostyshak wrote:
> > > > > I did not make any stats, cherrypicking single commit (likely close 
> > > > > to worst-case) gives me uncompressed 45 megs in blobs:
> > > > > $ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git 
> > > > > cat-file --batch-check |acut -f 3|asum
> > > > > 45175575
> > > >
> > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good
> > > > to know.
> > >
> > > No, 45MB uncompressed per _single_ commit. P
> >
> > We may want to unify the output of msgmerge to possibly minimize the 
> > differences in po-files.
> > For instance while remerging using '--width� --sort-output' may create the 
> > same output  on all platforms.
>
> I'm open to anything, but if there's something you want me specifically
> to do, please let me know the exact steps.
>
> Scott

Like the attached. (Not tested for automake)
The expected effect is big commit at next remerge (po-files only, no need to 
remerge the gmo files too).
It should pay of on later remerges.

Korneldiff --git a/development/cmake/modules/FindLyXGettext.cmake b/development/cmake/modules/FindLyXGettext.cmake
index 8533cbf..3e8a9b0 100755
--- a/development/cmake/modules/FindLyXGettext.cmake
+++ b/development/cmake/modules/FindLyXGettext.cmake
@@ -51,7 +51,7 @@ MACRO(GETTEXT_CREATE_TRANSLATIONS _potFile _firstPoFile)

   ADD_CUSTOM_COMMAND(
  OUTPUT ${_gmoFile}
- COMMAND ${GETTEXT_MSGMERGE_EXECUTABLE} --quiet --update --backup=none ${_absFile} ${_absPotFile}
+ COMMAND ${GETTEXT_MSGMERGE_EXECUTABLE} --quiet --update --backup=none --width€ --sort-output ${_absFile} ${_absPotFile}
  COMMAND ${GETTEXT_MSGFMT_EXECUTABLE} -c --statistics -o ${_gmoFile}.1 ${_absFile}
  COMMAND ${CMAKE_COMMAND} -E rename ${_gmoFile}.1 ${_gmoFile}
  DEPENDS ${_absPotFile} ${_absFile}
diff --git a/po/Makevars.template b/po/Makevars.template
index 0648ec7..c318c89 100644
--- a/po/Makevars.template
+++ b/po/Makevars.template
@@ -63,7 +63,7 @@ MSGMERGE_OPTIONS  # If you want to disable line wrapping when writing PO files, add
 # --no-wrap to MSGMERGE_OPTIONS, XGETTEXT_OPTIONS, and
 # MSGINIT_OPTIONS.
-MSGINIT_OPTIONS +MSGINIT_OPTIONS = --width€ --sort-output

 # This tells whether or not to regenerate a PO file when $(DOMAIN).pot
 # has changed.  Possible values are "yes" and "no".  Set this to no if


signature.asc
Description: This is a digitally signed message part.

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Sun, Sep 03, 2017 at 11:11:55PM +0200, Kornel Benko wrote:
> Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda 
> 
> > Scott Kostyshak wrote:
> > > > I did not make any stats, cherrypicking single commit (likely close to 
> > > > worst-case) gives me uncompressed 45 megs in blobs:
> > > > $ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git 
> > > > cat-file --batch-check |acut -f 3|asum
> > > > 45175575
> > > 
> > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good
> > > to know.
> > 
> > No, 45MB uncompressed per _single_ commit. P
> 
> We may want to unify the output of msgmerge to possibly minimize the 
> differences in po-files.
> For instance while remerging using '--width=80 --sort-output' may create the 
> same output  on all platforms.

I'm open to anything, but if there's something you want me specifically
to do, please let me know the exact steps.

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Kornel Benko]

Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda 
> Scott Kostyshak wrote:
> > > I did not make any stats, cherrypicking single commit (likely close to 
> > > worst-case) gives me uncompressed 45 megs in blobs:
> > > $ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git 
> > > cat-file --batch-check |acut -f 3|asum
> > > 45175575
> > 
> > 45MB for all gmo commits ever? That does not seem bad at all to me. Good
> > to know.
> 
> No, 45MB uncompressed per _single_ commit. P

We may want to unify the output of msgmerge to possibly minimize the 
differences in po-files.
For instance while remerging using '--width=80 --sort-output' may create the 
same output  on all platforms.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Thu, Aug 31, 2017 at 01:07:46PM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > > I did not make any stats, cherrypicking single commit (likely close to 
> > > worst-case) gives me uncompressed 45 megs in blobs:
> > > $ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git 
> > > cat-file --batch-check |acut -f 3|asum
> > > 45175575
> > 
> > 45MB for all gmo commits ever? That does not seem bad at all to me. Good
> > to know.
> 
> No, 45MB uncompressed per _single_ commit. P

Ah, thanks for the clarification.

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Pavel Sanda]

Scott Kostyshak wrote:
> > I did not make any stats, cherrypicking single commit (likely close to 
> > worst-case) gives me uncompressed 45 megs in blobs:
> > $ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git 
> > cat-file --batch-check |acut -f 3|asum
> > 45175575
> 
> 45MB for all gmo commits ever? That does not seem bad at all to me. Good
> to know.

No, 45MB uncompressed per _single_ commit. P

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Wed, Aug 30, 2017 at 04:48:36PM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > > b) git archive become easily huge just because of such changes
> > 
> > Do frequent commits of .gmo files significantly increase git archive?
> 
> I did not make any stats, cherrypicking single commit (likely close to 
> worst-case) gives me uncompressed 45 megs in blobs:
> $ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git 
> cat-file --batch-check |acut -f 3|asum
> 45175575

45MB for all gmo commits ever? That does not seem bad at all to me. Good
to know.

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Richard Heck]

On 08/30/2017 04:32 AM, Scott Kostyshak wrote:
> On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote:
>> Scott Kostyshak wrote:
>>> I think I have a fundamental misunderstanding. I thought that strings
>>> were supposed to be remerged before asking translators for translations.
>>> Then the translator returns the po file, and the po and the
>>> corresponding gmo files are committed. What is the purpose of remerging
>>> strings before a release? I was spoiled during 2.2.0 because I think
>>> Georg and Uwe took care of all translation-related issues. That ended up
>>> being a mistake because I realize that it is important for the release
>>> manager to know all parts of the process, so I'm trying to learn.
>> 1. Whenever new UI string is added or changed this change will propagate 
>> into .po files only via remerging strings.
>> 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code 
>> lines for string) changes as well - resulting into huge diff.
>>It gets even worse if different people do remerges because different 
>> archs produce slightly different formatting, resulting into even bigger 
>> patch (didn't check but we can easily talk megabytes per commit here).
>>
>> Point 1 implies it is good to remerge strings when you want translators 
>> working on up-to-date UI and if string change occurs (i.e. our minted flame).
>> Point 2 implies you don't want to do it more often except when really 
>> neccessary because
>> a) it creates hell when you do detailed seach through commit history via git 
>> log -p
> Workaround (which does not negate your point of course since it is a
> pain to remember):
>
> git log -p -- . ":(exclude)*.po"

# git config alias.lognopo "log -p -- . ':(exclude)*.po'"
# git lognopo

Richard

Re: LyX version 2.3.0 (beta 1)

[Pavel Sanda]

Scott Kostyshak wrote:
> > b) git archive become easily huge just because of such changes
> 
> Do frequent commits of .gmo files significantly increase git archive?

I did not make any stats, cherrypicking single commit (likely close to 
worst-case) gives me uncompressed 45 megs in blobs:
$ git diff-tree -r -c -M -C --no-commit-id  cf5d9e1 |acut -f 4 |  git cat-file 
--batch-check |acut -f 3|asum
45175575

You get similar size when looking at patch size:
$ git show --binary cf5d9e1 > /tmp/patch
$ ls -lh /tmp/patch
-rw-r--r-- 1 xxx xxx 43M Aug 30 16:44 /tmp/patch
$ tgz /tmp/patch #quick compress
-rw-r--r-- 1 xxx xxx 11M Aug 30 16:46 patch.tgz

Pavel

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > I think I have a fundamental misunderstanding. I thought that strings
> > were supposed to be remerged before asking translators for translations.
> > Then the translator returns the po file, and the po and the
> > corresponding gmo files are committed. What is the purpose of remerging
> > strings before a release? I was spoiled during 2.2.0 because I think
> > Georg and Uwe took care of all translation-related issues. That ended up
> > being a mistake because I realize that it is important for the release
> > manager to know all parts of the process, so I'm trying to learn.
> 
> 1. Whenever new UI string is added or changed this change will propagate into 
> .po files only via remerging strings.
> 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code 
> lines for string) changes as well - resulting into huge diff.
>It gets even worse if different people do remerges because different archs 
> produce slightly different formatting, resulting into even bigger patch 
> (didn't check but we can easily talk megabytes per commit here).
>
> Point 1 implies it is good to remerge strings when you want translators 
> working on up-to-date UI and if string change occurs (i.e. our minted flame).
> Point 2 implies you don't want to do it more often except when really 
> neccessary because
> a) it creates hell when you do detailed seach through commit history via git 
> log -p

Workaround (which does not negate your point of course since it is a
pain to remember):

git log -p -- . ":(exclude)*.po"

> b) git archive become easily huge just because of such changes

Do frequent commits of .gmo files significantly increase git archive?

> So one has to find certain compromise between 1/2. I would say that when you 
> are close to release/string freeze then any string change is worth to remerge 
> & commit.
> Also this time it's little easier because you already branched 2.3 so any 
> number of remerges won't spoil master history.
> You can test necessity of remerge by checking stats in remerge (number of 
> translated/fuzzy/untranslated strings changes for some language which is not 
> under extreme care of maintainers who can do remerges of their language only 
> - typical case of de,sk,fr?,it?).
> If you don't detect changes in stats, there is no need to remerge for 
> realease just to update code lines, because remerge IIRC happens 
> automatically inside tarball creation machinery.
> If you finally kick JMarc to give you svn access, regularly updated 
> translation status web page might be handy for you.
> 
> Ask if you have any question,

Thanks a lot for that detailed explanation. I will be more careful with
this, and am now building up a better understanding.

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Liviu Andronic]

On Thu, Aug 17, 2017 at 8:25 PM, Scott Kostyshak  wrote:

> Public release of LyX version 2.3.0beta1
> 
>
>
Ubuntu 'lyx2.3pre' packages are now available on the Development PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

The packages install independently of your existing stable 2.2.x
installation.

Regards,
Liviu



> We are proud to announce the first public beta of the new LyX 2.3 series.
> This pre-release is meant for testing and should not be used for serious
> work.
> For curious users who would like to test in order to help catch bugs before
> the 2.3.0 release, please back up all of your documents and be prepared for
> the worst to happen. Most users (who desire a stable LyX version) should
> not
> use this pre-release.
>
> The 2.3 series has a rich set of new features compared to the current
> stable
> series. An overview of the new features can be found here:
>
>   http://wiki.lyx.org/LyX/NewInLyX23
>
> You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/.
>
> We appreciate your help in testing this pre-release!
>
> The file lib/RELEASE-NOTES lists some known issues and problems compared
> to the current stable releases (LyX 2.2.x). We strongly recommend that
> packagers of LyX on various platforms and distributions read this file.
>
> As with any major release, this one comes with a lot of new features but
> also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either
> email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
> or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome.
> Please specify if the behavior you are reporting is different from behavior
> in a previous LyX version.
>
> If you have trouble using LyX or have a question, consult the
> documentation that comes with LyX (under Help) and the LyX wiki, which you
> will find at https://wiki.lyx.org/. You can also send email to the LyX
> users'
> list (lyx-users at lists.lyx.org).
>
> The LyX team.
> https://www.lyx.org
>
>

Re: LyX version 2.3.0 (beta 1)

[Pavel Sanda]

Scott Kostyshak wrote:
> I think I have a fundamental misunderstanding. I thought that strings
> were supposed to be remerged before asking translators for translations.
> Then the translator returns the po file, and the po and the
> corresponding gmo files are committed. What is the purpose of remerging
> strings before a release? I was spoiled during 2.2.0 because I think
> Georg and Uwe took care of all translation-related issues. That ended up
> being a mistake because I realize that it is important for the release
> manager to know all parts of the process, so I'm trying to learn.

1. Whenever new UI string is added or changed this change will propagate into 
.po files only via remerging strings.
2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code 
lines for string) changes as well - resulting into huge diff.
   It gets even worse if different people do remerges because different archs 
produce slightly different formatting, resulting into even bigger patch (didn't 
check but we can easily talk megabytes per commit here).
   
Point 1 implies it is good to remerge strings when you want translators working 
on up-to-date UI and if string change occurs (i.e. our minted flame).
Point 2 implies you don't want to do it more often except when really 
neccessary because
a) it creates hell when you do detailed seach through commit history via git 
log -p
b) git archive become easily huge just because of such changes

So one has to find certain compromise between 1/2. I would say that when you 
are close to release/string freeze then any string change is worth to remerge & 
commit.
Also this time it's little easier because you already branched 2.3 so any 
number of remerges won't spoil master history.

You can test necessity of remerge by checking stats in remerge (number of 
translated/fuzzy/untranslated strings changes for some language which is not 
under extreme care of maintainers who can do remerges of their language only - 
typical case of de,sk,fr?,it?).
If you don't detect changes in stats, there is no need to remerge for 
realease just to update code lines, because remerge IIRC happens automatically 
inside tarball creation machinery.
If you finally kick JMarc to give you svn access, regularly updated translation 
status web page might be handy for you.

Ask if you have any question,
Pavel

Re: LyX version 2.3.0 (beta 1)

[Richard Heck]

On 08/28/2017 01:09 AM, Scott Kostyshak wrote:
> On Sun, Aug 27, 2017 at 03:23:42AM +0200, Pavel Sanda wrote:
>> Scott Kostyshak wrote:
>>> Public release of LyX version 2.3.0beta1
>> Scott, did you put on lyx wiki the release steps you are using when 
>> releasing tarballs?
>> (If not, can you share it there?)
> I just updated the wiki with the basic steps I am doing. I will try to
> keep it updated as I make corrections (as it seems I should in the case
> of merging strings).
>
> https://wiki.lyx.org/Devel/ReleaseProcedure#toc1
>
> I hope to eventually organize all of my notes. I have some that are
> organized as "only for alpha1", "only for beta1", etc., and other
> informal things to check (e.g. for pre-releases use a different,
> scarier, form of ANNOUNCE).
>
>> It seems strings were not properly remerged for beta.
> I think I have a fundamental misunderstanding. I thought that strings
> were supposed to be remerged before asking translators for translations.
> Then the translator returns the po file, and the po and the
> corresponding gmo files are committed. What is the purpose of remerging
> strings before a release? I was spoiled during 2.2.0 because I think
> Georg and Uwe took care of all translation-related issues. That ended up 
> being a mistake because I realize that it is important for the release
> manager to know all parts of the process, so I'm trying to learn.

I don't know the answer to this, but I do remerge strings before doing
the mainteance releases,
mostly because it said to do so on the wiki. (I've updated a lot of that
myself now, so it's not as
I found it.)

Richard

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Sun, Aug 27, 2017 at 03:23:42AM +0200, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > Public release of LyX version 2.3.0beta1
> 
> Scott, did you put on lyx wiki the release steps you are using when releasing 
> tarballs?
> (If not, can you share it there?)

I just updated the wiki with the basic steps I am doing. I will try to
keep it updated as I make corrections (as it seems I should in the case
of merging strings).

https://wiki.lyx.org/Devel/ReleaseProcedure#toc1

I hope to eventually organize all of my notes. I have some that are
organized as "only for alpha1", "only for beta1", etc., and other
informal things to check (e.g. for pre-releases use a different,
scarier, form of ANNOUNCE).

> It seems strings were not properly remerged for beta.

I think I have a fundamental misunderstanding. I thought that strings
were supposed to be remerged before asking translators for translations.
Then the translator returns the po file, and the po and the
corresponding gmo files are committed. What is the purpose of remerging
strings before a release? I was spoiled during 2.2.0 because I think
Georg and Uwe took care of all translation-related issues. That ended up
being a mistake because I realize that it is important for the release
manager to know all parts of the process, so I'm trying to learn.

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Pavel Sanda]

Scott Kostyshak wrote:
> Public release of LyX version 2.3.0beta1

Scott, did you put on lyx wiki the release steps you are using when releasing 
tarballs?
(If not, can you share it there?)
It seems strings were not properly remerged for beta.
Pavel

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Thu, Aug 24, 2017 at 09:41:44AM +0200, Enrico Forestieri wrote:
> On Wed, Aug 23, 2017 at 09:38:04AM +0200, Enrico Forestieri wrote:

> > Miscellaneous, I would say.
> 
> I added it.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Enrico Forestieri]

On Wed, Aug 23, 2017 at 09:38:04AM +0200, Enrico Forestieri wrote:
> On Tue, Aug 22, 2017 at 10:33:51PM -0400, Scott Kostyshak wrote:
> > On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote:
> > > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote:
> > > > On 17/08/2017 20:25, Scott Kostyshak wrote:
> > > > > An overview of the new features can be found here:
> > > > > 
> > > > >http://wiki.lyx.org/LyX/NewInLyX23
> > > > 
> > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but 
> > > > it's not mentioned (yet).
> > > 
> > > Indeed, please feel free to put it. Or if you prefer that I do it that's
> > > fine too.
> > 
> > We do have the entry
> > 
> > "Option to use the LaTeX package minted for the typesetting of code
> > listings."
> > 
> > We could add the shell-escape feature as a separate entry, but I'm not
> > sure what we would put as the description. Something like the following?
> > 
> > -shell-escape can now be enabled only for specific documents, rather
> > than having to enable it globally in preferences.
> > 
> > Which category should we put it? Miscellaneous or "Image formats and
> > conversion"?
> 
> Miscellaneous, I would say.

I added it.

-- 
Enrico

Re: LyX version 2.3.0 (beta 1)

[Enrico Forestieri]

On Tue, Aug 22, 2017 at 10:33:51PM -0400, Scott Kostyshak wrote:
> On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote:
> > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote:
> > > On 17/08/2017 20:25, Scott Kostyshak wrote:
> > > > An overview of the new features can be found here:
> > > > 
> > > >http://wiki.lyx.org/LyX/NewInLyX23
> > > 
> > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but 
> > > it's not mentioned (yet).
> > 
> > Indeed, please feel free to put it. Or if you prefer that I do it that's
> > fine too.
> 
> We do have the entry
> 
> "Option to use the LaTeX package minted for the typesetting of code
> listings."
> 
> We could add the shell-escape feature as a separate entry, but I'm not
> sure what we would put as the description. Something like the following?
> 
> -shell-escape can now be enabled only for specific documents, rather
> than having to enable it globally in preferences.
> 
> Which category should we put it? Miscellaneous or "Image formats and
> conversion"?

Miscellaneous, I would say.

-- 
Enrico

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote:
> On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote:
> > On 17/08/2017 20:25, Scott Kostyshak wrote:
> > > An overview of the new features can be found here:
> > > 
> > >http://wiki.lyx.org/LyX/NewInLyX23
> > 
> > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's 
> > not mentioned (yet).
> 
> Indeed, please feel free to put it. Or if you prefer that I do it that's
> fine too.

We do have the entry

"Option to use the LaTeX package minted for the typesetting of code
listings."

We could add the shell-escape feature as a separate entry, but I'm not
sure what we would put as the description. Something like the following?

-shell-escape can now be enabled only for specific documents, rather
than having to enable it globally in preferences.

Which category should we put it? Miscellaneous or "Image formats and
conversion"?

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote:
> On 17/08/2017 20:25, Scott Kostyshak wrote:
> > An overview of the new features can be found here:
> > 
> >http://wiki.lyx.org/LyX/NewInLyX23
> 
> AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's 
> not mentioned (yet).

Indeed, please feel free to put it. Or if you prefer that I do it that's
fine too.

Thanks for pointing it out,

Scott


signature.asc
Description: PGP signature

Re: LyX version 2.3.0 (beta 1)

[Tommaso Cucinotta]

On 17/08/2017 20:25, Scott Kostyshak wrote:

An overview of the new features can be found here:

   http://wiki.lyx.org/LyX/NewInLyX23


AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's not 
mentioned (yet).

T.

LyX version 2.3.0 (beta 1)

[Scott Kostyshak]

Public release of LyX version 2.3.0beta1


We are proud to announce the first public beta of the new LyX 2.3 series.
This pre-release is meant for testing and should not be used for serious work.
For curious users who would like to test in order to help catch bugs before
the 2.3.0 release, please back up all of your documents and be prepared for
the worst to happen. Most users (who desire a stable LyX version) should not
use this pre-release.

The 2.3 series has a rich set of new features compared to the current stable
series. An overview of the new features can be found here:

  http://wiki.lyx.org/LyX/NewInLyX23

You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/.

We appreciate your help in testing this pre-release!

The file lib/RELEASE-NOTES lists some known issues and problems compared
to the current stable releases (LyX 2.2.x). We strongly recommend that
packagers of LyX on various platforms and distributions read this file.

As with any major release, this one comes with a lot of new features but
also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either
email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome.
Please specify if the behavior you are reporting is different from behavior
in a previous LyX version.

If you have trouble using LyX or have a question, consult the
documentation that comes with LyX (under Help) and the LyX wiki, which you
will find at https://wiki.lyx.org/. You can also send email to the LyX users'
list (lyx-users at lists.lyx.org).

The LyX team.
https://www.lyx.org



signature.asc
Description: PGP signature