Not a big deal, but just a note that our Embedded Objects manual will
fail to compile with LuaTeX when 2025-06-01 is released due to this
issue:
https://github.com/latex3/latex2e/issues/1725
I'll invert the corresponding tests when it's released.
Scott
signature.asc
Description: PGP signatur
Le 11/04/2025 à 08:54, Jürgen Spitzmüller a écrit :
Am Donnerstag, dem 10.04.2025 um 16:32 +0200 schrieb Jean-Marc
Lasgouttes:
This is a candidate for branch if Jürgen agrees with the change.
and here, as well.
Done. Thanks to both of you.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx
Am Donnerstag, dem 10.04.2025 um 16:32 +0200 schrieb Jean-Marc
Lasgouttes:
> This is a candidate for branch if Jürgen agrees with the change.
and here, as well.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
On 4/10/25 10:32 AM, Jean-Marc Lasgouttes wrote:
Le 10/04/2025 à 16:28, Jean-Marc Lasgouttes a écrit :
commit 4f20ac64d70282f1792abfeafa48a9fea8f89af1
Author: Jean-Marc Lasgouttes
Date: Wed Apr 9 14:29:14 2025 +0200
Do not to release inset before erasing it
It will be done by
Le 10/04/2025 à 16:28, Jean-Marc Lasgouttes a écrit :
commit 4f20ac64d70282f1792abfeafa48a9fea8f89af1
Author: Jean-Marc Lasgouttes
Date: Wed Apr 9 14:29:14 2025 +0200
Do not to release inset before erasing it
It will be done by eraseChar if needed. But when change tracking
On 5/10/24 14:27, Udicoudco wrote:
On Fri, May 10, 2024, 8:14 PM Richard Kimberly Heck
wrote:
commit 544cf0794eddcd44bc872e5a28c1a97ada109b1b
Author: Richard Kimberly Heck
Date: Fri May 10 13:14:09 2024 -0400
Remerge strings for 2.4.0 release
Riki,
Sorry for
On Fri, May 10, 2024, 8:14 PM Richard Kimberly Heck
wrote:
> commit 544cf0794eddcd44bc872e5a28c1a97ada109b1b
> Author: Richard Kimberly Heck
> Date: Fri May 10 13:14:09 2024 -0400
>
> Remerge strings for 2.4.0 release
>
Riki,
Sorry for reporting that in the last minute
We are intending to release LyX 2.3.8, the final maintenance release in
the 2.3.x series, soon. There should not have been many changes to
translatable strings since 2.3.7, but there will have been some. If
you'd like to update the translation, please do so by Friday, 12 April.
I'
There is the latexdiff tool, but I do not know if it works on WIidoze.
el
On 2024-01-22 23:13 , Jean-Marc Lasgouttes wrote:
[...]
> Different font, maybe ? Do you have the possibility to find what is the
> difference between 2.4 LaTeX output and 2.3 LaTeX output ?
[...]
--
lyx-devel mailing li
Didier,
which export are you using? I like pdf5 (lualatex which is powerful and
slow'ish) and then there is pdf4 (pdflatex).
el
On 2024-01-22 22:41 , didiergab...@free.fr wrote:
> Hi,
>
> Compared to version 2.3.7 and from the default settings the
> difference is obvious. The PDF (graphic) opti
On 1/22/24 17:05, didiergab...@free.fr wrote:
@José Matos
I notice that the images included in the text thread do not go
through… Here it is as an attachment
I think I got the image the first time. It may be that they do not show
up in the archive.
Riki
--
lyx-devel mailing list
lyx-deve
@José Matos
I notice that the images included in the text thread do not go through… Here it
is as an attachment
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
@ José Matos
- Mail original -
I also realize that I can no longer load images whose names contain accents.
In any case, that’s what’s happening with the file I just sent you. If I rename
the file:
SchemaCinematique.pdf to SchemaCinématique.pdf
then I can read “Error converting to a
I also realize that I can no longer load images whose names contain accents.
In any case, that’s what’s happening with the file I just sent you. If I rename
the file:
SchemaCinematique.pdf to SchemaCinématique.pdf
then I can read “Error converting to a readable format.”
Thanks for your patience…
On Mon, 2024-01-22 at 22:24 +0100, didiergab...@free.fr wrote:
> Thank you for your reply.
>
> I also noticed on this occasion that the export to a Lyx archive does
> not work…
> I have the following error message (see screenshot)
What do you get when you do "Help->About LyX", in French it should
Le 22/01/2024 à 21:41, didiergab...@free.fr a écrit :
Hi,
Compared to version 2.3.7 and from the default settings the difference
is obvious. The PDF (graphic) option is set to pdfview... But by
changing the parameters (custom, default system...) It's still just as
ugly... On the other hand, t
On 1/22/24 15:48, didiergab...@free.fr wrote:
Hi,
Compared to version 2.3.7 and from the default settings the difference
is obvious. The PDF (graphic) option is set to pdfview... But by
changing the parameters (custom, default system...) It's still just as
ugly... On the other hand, the pdflat
Hi,
Compared to version 2.3.7 and from the default settings the difference is
obvious.
The PDF (graphic) option is set to pdfview... But by changing the parameters
(custom, default system...) It's still just as ugly... On the other hand, the
pdflatex export is very good.
This is an installa
Hi,
Compared to version 2.3.7 and from the default settings the difference is
obvious.
The PDF (graphic) option is set to pdfview... But by changing the parameters
(custom, default system...) It's still just as ugly... On the other hand, the
pdflatex export is very good.
This is an installati
Op 15-01-2024 om 21:40 schreef Richard Kimberly Heck:
The LyX team is happy (and relieved) to announce the publication of the
first 'release candidate' for the long awaited 2.4.0. You can find
tarballs and binaries for Windows and OSX here:
http://ftp.lyx.org/pub/lyx/dev
On 16/01/2024 9:40 am, Richard Kimberly Heck wrote:
The LyX team is happy (and relieved) to announce the publication of
the first 'release candidate' for the long awaited 2.4.0. You can find
tarballs and binaries for Windows and OSX here:
http://ftp.lyx.org/pub/lyx/dev
On Jan 15, 2024, at 2:40 PM, Richard Kimberly Heck wrote:
> The LyX team is happy (and relieved) to announce the publication of the first
> 'release candidate' for the long awaited 2.4.0.
Just compiled it under Linux and was very happy to see that y’all fixed the
chonky (spec
The LyX team is happy (and relieved) to announce the publication of the
first 'release candidate' for the long awaited 2.4.0. You can find
tarballs and binaries for Windows and OSX here:
http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
Strictly speaking, we are releasing RC1 for testin
Am Mittwoch, dem 30.08.2023 um 15:29 +0200 schrieb Jürgen Spitzmüller:
> > + if you could do me a favor and commit
> > the few bits for UI tooltip and paragraph for users manual.
> > Riki might by re-releasing soon and I'm not on my usual computer to
> > push it.
>
> and this in a second step.
Am Mittwoch, dem 30.08.2023 um 14:42 +0200 schrieb Pavel Sanda:
> I quickly tested various script routes and all seem to work.
Thanks.
> I did not do any tests whether last changes affect the part of the
> code which uses various .bib fields.
I verified that this still works.
> ATM I propose yo
On Wed, Aug 30, 2023 at 10:24:08AM +0200, Jürgen Spitzmüller wrote:
> At least for how I would use it, this makes the feature immensely more
> useful.
Agreed, my script was doing this already and I did not relalize this
is not the default.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
On Wed, Aug 30, 2023 at 02:06:48PM +0200, Pavel Sanda wrote:
> I like this approach, let me test little bit if I see some problems.
I quickly tested various script routes and all seem to work.
I did not do any tests whether last changes affect the part of the code which
uses various .bib fields.
Am Mittwoch, dem 30.08.2023 um 14:06 +0200 schrieb Pavel Sanda:
> Yep, this is it!
>
> I like this approach, let me test little bit if I see some problems.
Great, let me know if you think it is ready (or if you found issues).
And thanks for testing.
--
Jürgen
--
lyx-devel mailing list
lyx-dev
On Wed, Aug 30, 2023 at 01:07:45PM +0200, Jürgen Spitzmüller wrote:
> Am Mittwoch, dem 30.08.2023 um 11:47 +0200 schrieb Jürgen Spitzmüller:
> > But independent of my patch we use this chain for the other
> > citation_view chains (url, file, doi, etc.). So we need to fix it
> > anyway.
>
> The new
Am Mittwoch, dem 30.08.2023 um 11:47 +0200 schrieb Jürgen Spitzmüller:
> But independent of my patch we use this chain for the other
> citation_view chains (url, file, doi, etc.). So we need to fix it
> anyway.
The new iteration of the patch uses our own viewers for local files
rather than QDeskto
Am Mittwoch, dem 30.08.2023 um 11:14 +0200 schrieb Pavel Sanda:
> - only first file from multiple files found is shown (fixable)
Not a new problem. As I wrote this is in the current script as well.
> - gimp is launched on the pdf file (fixable but not on the lyx side)
> although multiple pdf view
Am Mittwoch, dem 30.08.2023 um 11:12 +0200 schrieb Pavel Sanda:
> I understand your concern and as said do not oppose fixing this.
>
> On the other hand, I realized yesterday night, that the latest
> patch is game over for me. It relays the execution to Qt, which
> in turns relays that to xdg on l
On Wed, Aug 30, 2023 at 07:36:08AM +0200, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 29.08.2023 um 23:30 +0200 schrieb Pavel Sanda:
> > Quick check shows that the new approach breaks in multiple ways on my
> > system.
>
> I'd like to see those.
- only first file from multiple files found is sho
On Wed, Aug 30, 2023 at 07:36:03AM +0200, Jürgen Spitzmüller wrote:
> Don't see this problem, but if it is there, we can go async.
Seems working.
> > when more result on one query is found
> > - eat STDERR output to avoid mysterious crashes of spawned processes
>
> At the moment, the script on
Am Mittwoch, dem 30.08.2023 um 07:36 +0200 schrieb Jürgen Spitzmüller:
> At the moment, the script only opens the first matched file AFAICS.
> This will often not be the desired one (e.g. with multiple
> publications of an author per year).
>
> What it should do, and this cannot be done inside the
Am Dienstag, dem 29.08.2023 um 23:30 +0200 schrieb Pavel Sanda:
> Quick check shows that the new approach breaks in multiple ways on my
> system.
I'd like to see those.
> I'm sure there are ways to gradually fix this but I have different
> proposal.
>
> Would you mind that instead of just checki
Am Dienstag, dem 29.08.2023 um 17:50 +0200 schrieb Pavel Sanda:
> - Not waiting for a viewer to finish & spawn multiples instances of
> viewer
Don't see this problem, but if it is there, we can go async.
> when more result on one query is found
> - eat STDERR output to avoid mysterious crashes
On Tue, Aug 29, 2023 at 05:50:12PM +0200, Pavel Sanda wrote:
> On Tue, Aug 29, 2023 at 05:27:16PM +0200, Jürgen Spitzmüller wrote:
> > Am Dienstag, dem 29.08.2023 um 17:23 +0200 schrieb Pavel Sanda:
> > > I am afraid this will break on the problems I tried to handle inside
> > > the script and will
On Tue, Aug 29, 2023 at 05:27:16PM +0200, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 29.08.2023 um 17:23 +0200 schrieb Pavel Sanda:
> > I am afraid this will break on the problems I tried to handle inside
> > the script and will complicate the situation if you want to slip your
> > own scripts in
Am Dienstag, dem 29.08.2023 um 17:23 +0200 schrieb Pavel Sanda:
> I am afraid this will break on the problems I tried to handle inside
> the script and will complicate the situation if you want to slip your
> own scripts in the pipeline.
Like which problems exactly?
> If you have strong feeling t
On Tue, Aug 29, 2023 at 04:57:01PM +0200, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 29.08.2023 um 14:52 +0200 schrieb Jürgen Spitzmüller:
> > OTOH if we would make the lyxpaperview script return a path rather
> > than opening found documents itself, we could use the same message
> > and be more
Am Dienstag, dem 29.08.2023 um 16:57 +0200 schrieb Jürgen Spitzmüller:
> Am Dienstag, dem 29.08.2023 um 14:52 +0200 schrieb Jürgen
> Spitzmüller:
> > OTOH if we would make the lyxpaperview script return a path rather
> > than opening found documents itself, we could use the same message
> > and be
Am Dienstag, dem 29.08.2023 um 14:52 +0200 schrieb Jürgen Spitzmüller:
> OTOH if we would make the lyxpaperview script return a path rather
> than opening found documents itself, we could use the same message
> and be more precise here.
Like in the attached.
--
Jürgen
diff --git a/lib/scripts/ly
On Tue, Aug 29, 2023 at 03:13:47PM +0200, Pavel Sanda wrote:
> See the attached for the hint and below:
now with the patch... p
diff --git a/src/frontends/qt/ui/PrefEditUi.ui b/src/frontends/qt/ui/PrefEditUi.ui
index 79820b7c7d..39b05dcbc5 100644
--- a/src/frontends/qt/ui/PrefEditUi.ui
+++ b/src/f
On Tue, Aug 29, 2023 at 01:16:40PM +0200, Pavel Sanda wrote:
> 3 is disabled by default and hint can be added later as well.
See the attached for the hint and below:
(ATM I'm not on the machine with commit access, so please add yourself if you
are pushing new release out.)
For the secti
Am Dienstag, dem 29.08.2023 um 14:44 +0200 schrieb Jürgen Spitzmüller:
> I had to introduce a specific message for the EXTERNAL case, as we do
> not have an URI at hand in this case.
OTOH if we would make the lyxpaperview script return a path rather than
opening found documents itself, we could us
On Tue, Aug 29, 2023 at 02:16:01PM +0200, Daniel wrote:
> Or would that be too annoying?
Quite a lot.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Dienstag, dem 29.08.2023 um 13:22 +0200 schrieb Pavel Sanda:
> That would be much appreciated.
>
> Please go on if you have time, I sent my edits in the thread itself.
Committed. Please check.
I had to introduce a specific message for the EXTERNAL case, as we do
not have an URI at hand in thi
On Tue, Aug 29, 2023 at 02:16:01PM +0200, Daniel wrote:
> On 2023-08-29 13:16, Pavel Sanda wrote:
> > On Mon, Aug 28, 2023 at 08:49:30PM -0400, Richard Kimberly Heck wrote:
> > > > Options are, we postpone this for 2.4.1 as this is not fileformat
> > > > change.
> > > > If deemed too dangerous, we
On 2023-08-29 13:16, Pavel Sanda wrote:
On Mon, Aug 28, 2023 at 08:49:30PM -0400, Richard Kimberly Heck wrote:
Options are, we postpone this for 2.4.1 as this is not fileformat change.
If deemed too dangerous, we can temporarily disable the feature and enable
it again with the safeguards, your c
On Tue, Aug 29, 2023 at 10:39:55AM +0200, Jürgen Spitzmüller wrote:
> Am Montag, dem 28.08.2023 um 21:26 +0200 schrieb Pavel Sanda:
> > I do not have currently capacity to work on the citation/url links opening
> > policy. As it seems there is some vague consensus on how to proceed and
> > that wil
On Mon, Aug 28, 2023 at 08:49:30PM -0400, Richard Kimberly Heck wrote:
> >Options are, we postpone this for 2.4.1 as this is not fileformat change.
> >If deemed too dangerous, we can temporarily disable the feature and enable
> >it again with the safeguards, your call here.
>
> Can you remind me w
Am Montag, dem 28.08.2023 um 21:26 +0200 schrieb Pavel Sanda:
> I do not have currently capacity to work on the citation/url links
> opening
> policy. As it seems there is some vague consensus on how to proceed
> and
> that will involve new string(s).
>
> Options are, we postpone this for 2.4.1 a
On 8/28/23 15:26, Pavel Sanda wrote:
On Mon, Aug 28, 2023 at 12:25:31PM -0400, Richard Kimberly Heck wrote:
Do we seem ready for another release? My sense is that things have calmed
down again. If so, then we might go ahead and do one and then immediately
freeze strings to allow our translators
On Mon, Aug 28, 2023 at 12:25:31PM -0400, Richard Kimberly Heck wrote:
> Do we seem ready for another release? My sense is that things have calmed
> down again. If so, then we might go ahead and do one and then immediately
> freeze strings to allow our translators to start their work.
On Mon, Aug 28, 2023 at 07:09:51PM +0200, Jürgen Spitzmüller wrote:
> Am Montag, dem 28.08.2023 um 18:31 +0200 schrieb Jean-Marc Lasgouttes:
> > Le 28/08/2023 à 18:25, Richard Kimberly Heck a écrit :
> > > Do we seem ready for another release? My sense is that things have
>
Am Montag, dem 28.08.2023 um 18:31 +0200 schrieb Jean-Marc Lasgouttes:
> Le 28/08/2023 à 18:25, Richard Kimberly Heck a écrit :
> > Do we seem ready for another release? My sense is that things have
> > calmed down again. If so, then we might go ahead and do one and
> >
Le 28/08/2023 à 18:25, Richard Kimberly Heck a écrit :
Do we seem ready for another release? My sense is that things have
calmed down again. If so, then we might go ahead and do one and then
immediately freeze strings to allow our translators to start their work.
I think we are.
JMarc
Do we seem ready for another release? My sense is that things have
calmed down again. If so, then we might go ahead and do one and then
immediately freeze strings to allow our translators to start their work.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman
Le 16/11/2022 à 16:49, Pavel Sanda a écrit :
The difference is that --enable-qt5 will do nothing and --disable-qt5 will
now be needed to compile with qt4.
Ok, if you don't want to kill --enable-qt5 and various -with-qt-* we should be
fine.
The patch is in now. As you can see, it is pretty tr
On Wed, 2022-11-16 at 16:49 +0100, Pavel Sanda wrote:
> Ok, if you don't want to kill --enable-qt5 and various -with-qt-* we
> should be fine.
>
> Pavel
Ah, now I see your point. For me that was not even a question. :-)
In the sense that we change the default but the option flags remain.
--
José
On Wed, Nov 16, 2022 at 04:28:05PM +0100, Jean-Marc Lasgouttes wrote:
> Le 16/11/2022 ?? 16:16, Pavel Sanda a écrit :
> >I don't think any. But my point was that the current ones who use qt5
> >must use specific switches for configure and it might be better not
> >to disrupt that. If the proposed d
Am Wed, 16 Nov 2022 16:28:05 +0100
schrieb Jean-Marc Lasgouttes :
> Le 16/11/2022 à 16:16, Pavel Sanda a écrit :
> > I don't think any. But my point was that the current ones who use qt5
> > must use specific switches for configure and it might be better not
> > to disrupt that. If the proposed de
Le 16/11/2022 à 16:16, Pavel Sanda a écrit :
I don't think any. But my point was that the current ones who use qt5
must use specific switches for configure and it might be better not
to disrupt that. If the proposed defaults transition won't change
functional qt5 configure switches I have no obje
On Wed, Nov 16, 2022 at 03:00:09PM +, José Matos wrote:
> On Wed, 2022-11-16 at 14:16 +0100, Pavel Sanda wrote:
> > The disadvantage of this is that it disrupts maintaners scripts to
> > build
> > a new version which is supposed to bring rather minor fixes...
> >
> > Pavel
>
> That is true in
4 when building 2.3?
We can add this to the release notes and that can also be used to
signal that Qt4 support will be removed after 2.4.
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Tue, Nov 15, 2022 at 09:49:04PM +0100, Jean-Marc Lasgouttes wrote:
> I have a disruptive question : would a patch setting Qt5 as default platform
> be accepted ? Not many people can compile on Qt4 these days.
The disadvantage of this is that it disrupts maintaners scripts to build
a new version
with gradual freezing in mid Jan, so if we could
aim for the tarball release in mid Dec, everything would be smooth. As said
don't hesitate to ask for a help if in time pressure...
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Dienstag, dem 15.11.2022 um 13:56 -0500 schrieb Richard Kimberly
Heck:
> OK, I'll find some time to go through the tickets on trac and see
> what might be included.
Please let me know if you need help identifying them.
Thanks,
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://l
On 11/15/22 15:49, Jean-Marc Lasgouttes wrote:
Le 15/11/2022 à 19:56, Richard Kimberly Heck a écrit :
On 11/15/22 12:14, Jürgen Spitzmüller wrote:
Am Dienstag, dem 15.11.2022 um 12:01 -0500 schrieb Richard Kimberly
Heck:
Yes, I'm happy to do that. I have not been following the list
closely, so
Le 15/11/2022 à 19:56, Richard Kimberly Heck a écrit :
On 11/15/22 12:14, Jürgen Spitzmüller wrote:
Am Dienstag, dem 15.11.2022 um 12:01 -0500 schrieb Richard Kimberly
Heck:
Yes, I'm happy to do that. I have not been following the list
closely, so don't know what patches might need to go in, bu
On 11/15/22 12:14, Jürgen Spitzmüller wrote:
Am Dienstag, dem 15.11.2022 um 12:01 -0500 schrieb Richard Kimberly
Heck:
Yes, I'm happy to do that. I have not been following the list
closely, so don't know what patches might need to go in, but I'll
have some time over the next few weeks.
I think
Am Dienstag, dem 15.11.2022 um 12:01 -0500 schrieb Richard Kimberly
Heck:
> Yes, I'm happy to do that. I have not been following the list
> closely, so don't know what patches might need to go in, but I'll
> have some time over the next few weeks.
I think there are some pending tickets on trac. al
On 11/15/22 07:33, Pavel Sanda wrote:
Hi Riki and others,
given the current schedule, 2.4 is not coming out soon I think it would be nice
to at least release the collected fixes of 2.3.7 so they can make into next
debian stable.
Riki, would you be willing to make 2.3.7 release any time soon
Hi Riki and others,
given the current schedule, 2.4 is not coming out soon I think it would be nice
to at least release the collected fixes of 2.3.7 so they can make into next
debian stable.
Riki, would you be willing to make 2.3.7 release any time soon?
I can offer some helping hand in case
On Fri, Oct 30, 2020 at 03:41:56PM -0400, Richard Kimberly Heck wrote:
>
>
> Forwarded Message
> Subject: Re: Testing Release of 2.4.0 Development Branch
> Date: Fri, 30 Oct 2020 22:39:38 +0300
> From: Baris Erkus
> To: Richard Kim
velopment
> releases, this would be very simple too.
I think that this is not your first remark about prime numbers on release
numbers. :-)
We follow a green policy and recycle arguments in these threads. :-)
BTW in the same vein I propose to use perfect numbers. :-)
In this case what I meant is tha
On Fri, Jan 15, 2021 at 10:11:03AM +0100, Jean-Marc Lasgouttes wrote:
> I propose something where prime numbers are used for development releases,
> this would be very simple too.
You made my day :)) P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-dev
version 5, and it already the seventh release where this
numbering schme is used.
In Fedora Rawhide (to be Fedora 34) the current version of gcc is 11.0.0. That
immediately shows that this is not the stable version. The first stable
version will be 11.1.
Yes, it is very immediate. All you have to do
On Wednesday, January 13, 2021 8:27:28 PM WET Pavel Sanda wrote:
> The question really is why it should be wrong to give new major version
> +0.1.
>
> Anyway, I do not see that this subthread is moving in a constructive
> direction, so it's perhaps best to agree that we disagree
I agree, I tried
On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote:
> Fortunately I do not have to rely only on my memory
>
> Wiki: Sat Nov 15 18:59:02 2008 : LyX 2_0: Wiki pages creation
> SVN:Sun Dec 7 18:09:18 2008 : [Cvslog] r27798 Makefile.am: PSpell and
> ISpell was removed for LyX 2.0
-- which is
at least for some of us more comfy :)
> Regarding anniversaries they use to happen once a year. :-)
:)
> So instead of theoretical case let us look concretely in the the next release
> changes https://wiki.lyx.org/LyX/NewInLyX24
>
> Does this looks like a minor update
sons are from a developer point of view.
Again IMHO, important as they are, all those aspects that you refer that are
implementation details.
By hearth, and without looking in to the release notes, I would say that the:
* introduction of modules;
* the beamer interface overhaul that makes it easi
mps to +1 version for unusual events (like unicode, Qt3->Qt4, XML,
> anniversaries).
+1
> > My other remark is that are not changes that meet the litmus test of being
> > considered important enough to deserve the major version jump. There has
> > not
> > been non
s that meet the litmus test of being
> considered important enough to deserve the major version jump. There has not
> been none in the previous 20 years. If we applied this reasoning we would
> start work on the release of LyX 1.11.
Well, almost yes, we could be talking about 2.1 now and I
deserve the major version jump. There has not
been none in the previous 20 years. If we applied this reasoning we would
start work on the release of LyX 1.11.
> Pavel
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Wed, Jan 13, 2021 at 01:55:24PM +, José Abílio Matos wrote:
> > I hope my memory serves me well, but the major reason we did not go the
> > predictable route of 1.6, 1.7, 1.8, 1.9, 2.0, 2.1 etc was your own push for
> > 2.0 at the Berlin meeting. I can even remember at which corner of the ro
the room
> were you standing when voicing the issue
The meeting was on 2008 and the actual change was in 2010. So it was not at
all an immediate effect.
> I added justification for 2.0 as a celebration of anniversary of the project
> in the release notes, but that was secondary to that
iversary of the project in
the
release notes, but that was secondary to that push and would not happen without.
Actually I was not even against that particular bump, but to use it now as an
argument against predictability for yeat another unpredictable jump does not
look fair :)
Pavel
--
lyx-dev
at version 5, and it already the seventh release where this
numbering schme is used.
In Fedora Rawhide (to be Fedora 34) the current version of gcc is 11.0.0. That
immediately shows that this is not the stable version. The first stable
version will be 11.1.
--
José Abílio
--
lyx-devel mailing l
Le 13/01/2021 à 02:27, José Abílio Matos a écrit :
The development version, unreleased version is 3.0.0.
As soon as the first test version is released it gets the 3.0.1, the next one
is 3.0.2 and so on.
When the release candidates stage is over and a stable version is released as
LyX 3.1.
If a
47&w=2
FWIW this was January-February 2010.
In particular the 1.5 release where we changed to Unicode/UTF-8 it was in a
sense a fundamental change.
> but a Python-based conversion script manages forward/backward
> compatibility in such a way that I regard the "API" as u
Le 12/01/2021 à 11:00, Pavel Sanda a écrit :
- I prefer to stay with single digits as long as possible because it's
easier to remember/communicate them. The moment the version numbers
go beyond 10, you tend to lose track of versions (experience with
firefox-like scheme).
Firefox change
On Mon, Jan 11, 2021 at 03:58:48PM -0700, Joel Kulesza wrote:
> So, this is effectively how things operate now except collapsing the fourth
> entry into the third. Once a breaking change occurs, then the jump would
> be made from 2->3.
I agree. If the 4th number is too disturbing collapsing it in
On Mon, Jan 11, 2021 at 08:59:55PM +, José Abílio Matos wrote:
> Since we our release schedule is every two years this will keep us in low
> numbers for a long time.
>
> What do you think?
Not surprisingly, I'd propose to stay where we are.
The reasons are two:
- I pr
be 2.4.1, 2.4.2,...
>
> If, for instance, there is a problem in the stable version 2.4.2 then we
> can immediately release version 2.4.3.
>
>
> So, this is effectively how things operate now except collapsing the
> fourth entry into the third. Once a breaking change occur
On Mon, Jan 11, 2021 at 2:18 PM Richard Kimberly Heck
wrote:
> On 1/11/21 3:59 PM, José Abílio Matos wrote:
>
> Today in the virtual meeting we discussed several of the issues regarding
> the next major version for the stable release.
>
> I am proposing here to change to a S
On Mon, 11 Jan 2021 at 22:36, Jean-Marc Lasgouttes
wrote:
> Le 11/01/2021 à 22:30, Thibaut Cuvelier a écrit :
> > The basic principle of semantic versioning is based on the notion of
> > public API. What is the public API of LyX?
>
> The file format, layout file format and pref file format. These
Le 11/01/2021 à 22:30, Thibaut Cuvelier a écrit :
The basic principle of semantic versioning is based on the notion of
public API. What is the public API of LyX?
The file format, layout file format and pref file format. These are
stable across stable versions.
JMarc
--
lyx-devel mailing lis
On Mon, 11 Jan 2021 at 22:00, José Abílio Matos wrote:
> Today in the virtual meeting we discussed several of the issues regarding
> the next major version for the stable release.
>
> I am proposing here to change to a Semantic Versioning scheme. This can is
> best described
1 - 100 of 2318 matches
Mail list logo
