New release MathGL v.8.0

66 views
Skip to first unread message

Alexey Balakin

unread,
Jan 1, 2022, 9:06:20 AM1/1/22
to MathGL
I glad to announce new release of MathGL. There are change version numbering according Debian rules, and add accurate line segment and quadrangle/triangle face cutting at axis border crossing. Detailed changes are denoted here.

Rafael Laboissière

unread,
Jan 7, 2022, 3:40:37 AM1/7/22
to mat...@googlegroups.com
Hello Alexey,

Thank you for releasing version 8.0 of MathGL. I appreciate your effort
for changing the version numbering scheme. However, there are still some
issues, which I explain below. Please, refer to my previous, extensive
message on this issue :
https://groups.google.com/g/mathgl/c/D4zTEYXB0jw/m/6vpsJwUcDAAJ

First of all, it is not necessary to have the same numbers for the
versions of the MathGL release and the library version. You could have
released version 3 of MathGL and have independently bumped (or not) the
SOVERSION.

Second, the SOVERSION of the library should be a single integer number
(in the current case, it should be "8"), and not "8.0" as it is now.
Also you should define the property VERSION for the libraries (in the
current case, it should be "8.0.0"). After building, symbolic links like
the following one will be created:

/usr/lib/libmgl.so.8 -> libmgl.so.8.0.0

Finally, it would be appropriate to have separate version numbers for
each library, that should evolve according to the rules that I wrote in
my previous message.

I am attaching to this message a patch that addresses all the issues
above. In particular, it defines separated SOVERSION and VERSION numbers
for each library. Note that, with this patch, the versioning definitions
will be scattered throughout the source files. For instance, for the glut
library (in widgets/CMakeLists.txt):

set(mgl_glut_SOVERSION 8)
set(mgl_glut_VERSION 8.0.0)

The mgl_add_lib (in the toplevel CMakeLists.txt) function is modified,
such that the SOVERSION and the VERSION numbers are now passed as 2nd and
3rd arguments, for instance:

mgl_add_lib(glut ${mgl_glut_SOVERSION} ${mgl_glut_VERSION} glut.cpp ../include/mgl2/glut.h)

I tested the patch by building the Debian package with it. The build
worked fine.

I hope this patch will suit you. If you authorizes me, I will integrate
it into the forthcoming Debian package for MathGL 8.0 .

Best regards,

Rafael Laboissière

* Alexey Balakin <mathgl....@gmail.com> [2022-01-01 06:06]:

> I glad to announce new release of MathGL. There are change version
> numbering according Debian rules, and add accurate line segment and
> quadrangle/triangle face cutting at axis border crossing. Detailed changes
> are denoted here <http://mathgl.sourceforge.net/doc_en/News.html>.
>
> --
> You received this message because you are subscribed to the Google Groups "MathGL" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mathgl+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mathgl/9dc4d618-a456-461e-bc36-a0e779e46320n%40googlegroups.com.
libs-version-soversion.patch

Alexey Balakin

unread,
Jan 7, 2022, 5:23:18 PM1/7/22
to mat...@googlegroups.com
Dear Rafael,

I try to implement something similar in SVN rev. 1706. Is it OK for you?
If yes then I can make release 8.0.1 shortly.

Unfortunately, I think that introduction of different soversions for
different parts of MathGL is bad idea, since it will lead to errors in
future (I may, and most probably will, forgot to update all of them).

07.01.2022 11:40, Rafael Laboissière пишет:
--
Kind regards,
Alexey Balakin

Rafael Laboissière

unread,
Jan 11, 2022, 10:38:31 AM1/11/22
to mat...@googlegroups.com
* Alexey Balakin <mathgl....@gmail.com> [2022-01-08 01:23]:

> I try to implement something similar in SVN rev. 1706. Is it OK for
> you? If yes then I can make release 8.0.1 shortly.

SVN r1706 looks fine for me. Go ahead.

> Unfortunately, I think that introduction of different soversions for
> different parts of MathGL is bad idea, since it will lead to errors in
> future (I may, and most probably will, forgot to update all of them).

Ok, let us keep a single soversion for all libraries.

Thanks,

Rafael
Reply all
Reply to author
Forward
0 new messages