Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-25 Thread Stephane Mottelet 

Hello,

Thanks for your mesage.

Independently of the version numbering  the main interesting information is 
about the frequency of the releases, which is a good thing and shows the future 
investment of the 3DS Scilab team. I just hope that users will get used to 
trash their current version of Sclab to use the new one every 6 month, 
otherwise helping them will become very complicated. These days it was quite 
easy because people were using mainly 5.5.2 and 6.1.1 version ! Habits will 
have to change...

S.

---
Stephane Mottelet


Le 2023-02-25 14:33, A. Khorshidi a écrit :



Dear Stéphane,



I really appreciate you being so compassionate about making Scilab the best it 
can be.

There is no doubt that the points you make are absolutely valid, and I hope 
that Scilab's administration will make a wise decision to continue to maintain 
the project in the future.

Merci,
Mehran


From: Stéphane Mottelet 
Sent: Thursday, February 23, 2023 2:36 AM
To: Stéphane Mottelet 
Subject: Re: Scilab needs you

Hello,

Some of you have already answered and it is still time to express
yourself. Below are the links to the threads on the archive of the
mailing list :

original message:

https://www.mail-archive.com/users@lists.scilab.org/msg11014.html

my answer:

https://www.mail-archive.com/users@lists.scilab.org/msg11015.html

If you need to re-subscribe to the mailing list to be able to send your
message use the following link:

https://lists.scilab.org/mailman/listinfo/users

This is my last message sent to you directly about that subject.

S.

Le 20/02/2023 à 09:11, Stéphane Mottelet a écrit :

Dear Scilab users and developpers,

You have been using or are still using Scilab, as a user and/or a
toolbox author, maybe you are also packaging Scilab. These days
there's a hot topic on d...@lists.scilab.org  (look for the message
with title "Scilab releases schedule / End of Windows 32-bit support")
concerning a potential change of the versioning scheme which could
seriously dammage the relations between Scilab and the OSS community.
If you have some spare time and think that Scilab is worth it please
give your thoughts in the discussion thread. There is another thread
in us...@scilab.list.org you can express in any of the two.

Sincerely yours,


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-25 Thread A. Khorshidi 
Dear Stéphane,


I really appreciate you being so compassionate about making Scilab the best it 
can be.

There is no doubt that the points you make are absolutely valid, and I hope 
that Scilab's administration will make a wise decision to continue to maintain 
the project in the future.

Merci,
Mehran


From: Stéphane Mottelet 
Sent: Thursday, February 23, 2023 2:36 AM
To: Stéphane Mottelet 
Subject: Re: Scilab needs you

Hello,

Some of you have already answered and it is still time to express
yourself. Below are the links to the threads on the archive of the
mailing list :

original message:

https://www.mail-archive.com/users@lists.scilab.org/msg11014.html

my answer:

https://www.mail-archive.com/users@lists.scilab.org/msg11015.html

If you need to re-subscribe to the mailing list to be able to send your
message use the following link:

https://lists.scilab.org/mailman/listinfo/users

This is my last message sent to you directly about that subject.

S.

Le 20/02/2023 à 09:11, Stéphane Mottelet a écrit :
> Dear Scilab users and developpers,
>
> You have been using or are still using Scilab, as a user and/or a
> toolbox author, maybe you are also packaging Scilab. These days
> there's a hot topic on d...@lists.scilab.org  (look for the message
> with title "Scilab releases schedule / End of Windows 32-bit support")
> concerning a potential change of the versioning scheme which could
> seriously dammage the relations between Scilab and the OSS community.
> If you have some spare time and think that Scilab is worth it please
> give your thoughts in the discussion thread. There is another thread
> in us...@scilab.list.org you can express in any of the two.
>
> Sincerely yours,
>
--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-22 Thread Federico Miyara 


Also, as has been already mentioned, the year version may or may not imply an 
actual major version (i.e., changes that imply an important or significant API 
change, which not necessarily means backward incompatibility) so to find out it 
will be necessary to dive into the change log. The only new information the 
proposed version numbering system would give is the year of release which is 
only relevant for historical reasons (and anyway can be easily found). 
Moreover, for most users (those who use the current version at a given time), 
it would be a redundant information since users know the year they live in.

Regards,

Federico Miyara

On 22/02/2023 07:07, Lamy Alain wrote:

Dear Scilab users / team,

Just one opinion among others:

That's nice to have new Scilab releases regularly, provided of course that 
backward compatibility is guaranteed us much as possible, except maybe for 
major versions.

But I don't see the need for changing the versioning convention.

For instance knowing that Scilab version is 5.x.x or 6.x.x is major information 
that is easy to notice at a glance.
That's not the case if the version major number becomes a year number. And it 
let people think that the version from some given year could potentially be 
incompatible with the version from the previous year, which is not good news.

Alain Lamy


___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 

https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/








[Avast logo] 

El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
www.avast.com



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-22 Thread COUVERT Vincent 
Dear Alain,

Thanks for your message.

For Scilab users, incompatibility mainly comes from functions renaming, removal 
or incompatible prototype change. In the past, this kind of change could even 
occur in patch versions (which could be released more than once a year).
With this new release schedule and numbering, our aim is not to break 
compatibility more often. We just want to clarify what will be the contents of 
releases and when they will be available (containing incompatibilities or not).

Vincent



-Original Message-
From: users  On Behalf Of Lamy Alain
Sent: Wednesday, February 22, 2023 11:07 AM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of 
Windows 32-bit support

Dear Scilab users / team,

Just one opinion among others:

That's nice to have new Scilab releases regularly, provided of course that 
backward compatibility is guaranteed us much as possible, except maybe for 
major versions.

But I don't see the need for changing the versioning convention.

For instance knowing that Scilab version is 5.x.x or 6.x.x is major information 
that is easy to notice at a glance.
That's not the case if the version major number becomes a year number. And it 
let people think that the version from some given year could potentially be 
incompatible with the version from the previous year, which is not good news.

Alain Lamy


___
users mailing list - users@lists.scilab.org Click here to unsubscribe: 
<mailto:users-unsubscr...@lists.scilab.org>
https://lists.scilab.org/mailman/listinfo/users
___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: <mailto:users-unsubscr...@lists.scilab.org>
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-22 Thread Lamy Alain 
Dear Scilab users / team,

Just one opinion among others:

That's nice to have new Scilab releases regularly, provided of course that 
backward compatibility is guaranteed us much as possible, except maybe for 
major versions.

But I don't see the need for changing the versioning convention.

For instance knowing that Scilab version is 5.x.x or 6.x.x is major information 
that is easy to notice at a glance.
That's not the case if the version major number becomes a year number. And it 
let people think that the version from some given year could potentially be 
incompatible with the version from the previous year, which is not good news.

Alain Lamy


___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-20 Thread Claus Futtrup 

Dear Scilabers

I'm not a professional software developer, but a user of Scilab for more
than 10 years.

I am positive to a 6-month release schedule. I am also a bit surprised,
since last Scilab release was almost two years ago and I'm wondering how
the planned frequent release schedule can be kept.

I am in favor of keeping the versioning the way it has been for many
years, such that a version 7 is only expected for a major release, and
it might be many years in the future before it happens.

Personally I would like to see some releases that make major steps
(leaps) forward, not only bug fixes and minor updates. Incompatible
updates is allowed with major releases, if it serves a purpose.

Best regards,
Claus Futtrup

P.S. I haven't received any email from this mailing list since end of
April 2022.

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-20 Thread CHEZE David 227480 
Dear all,

I’m not professional software developers while I develop a few Scilab modules 
for internal use in research organization (mostly around energy technologies 
and systems, at building and energy network scale), Stephane’s proposal sounds 
reasonable to cope with various perspectives around Scilab uses and 
developments: while having the year based version is nice to animate the Scilab 
community by raising users curiosity about new features and improvements (++, 
also to promote Scilab to new users and students), regarding previous Scilab 
developments and compatibility issues I feel it is required to keep the ‘true 
version‘ based on technical development requirements (++).
My two cents…

David



De : dev  De la part de Stephane Mottelet
Envoyé : samedi 18 février 2023 16:30
À : List dedicated to the development of Scilab ; Users 
mailing list for Scilab 
Objet : Re: [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit 
support


Hello,

Please allow me to react to these answers as I feel also very concerned with 
this potential evolution. The year-base major number won't ease a better 
visibility about API changes. It will force us to systematically add a a notice 
saying  something like :

"Don't worry about the major version increase because this time there will not 
be any API change"

or its contrary :

"Unlike previous year, there will be major API changes in this new major 
version so you will have to upgrade your toolboxes".

Moreover, the rationale about the "compatibility with other tools (Matlab, 
Office, Excel, ...)" has no sense because these tools are commercial and closed 
source software. However, I admit that having the year information can be 
valuable for all users as it will allow to know immediately when a given 
version of Scilab was released.

The ideal scenario would be to use both systems: keep the usual not year-based 
major.minor.patch version numbering (SCI_VERSION_MAJOR, 
SCILAB_VERSION_MINOR,SCILAB_VERSION_MAINTENANCE in our headers) together with a 
release name (SCILAB_VERSION_STRING in our headers).

Presently Scilab is already ready for that since we have the following 
different outputs, for example here with a CI (continuous integration) build:

--> getversion
 ans  =

  "scilab-mr3-0237210d"

--> getversion("scilab")
 ans  =

   6.   1.   2.   1.677D+09

Here SCILAB_VERSION_STRING="scilab-mr3-0237210d" has been given during the CI 
and is completely arbitrary and not related to the second output which gives 
the true information about changes at the code level.

Having a new release schedule half-year based is completely independent of this 
need of version numbering. I am fine with the fact that you may need a kind of 
"branding" since almost all of the developers of Scilab are employed by a 
private entity who "owns" at least the "Scilab" name (but a big part of Scilab 
code owns to individual authors) to me that's the main rationale. However you 
should be aware that open-source software never completely belongs to its 
authors but also to its numerous users.

Since it beginnings Scilab had a complicated story and its governance has 
always been a mystery for most people using it. But in the last 5 years the 
huge work of promoting Scilab and keeping it alive and kicking was made by the 
users themselves. So, this proposed unilateral change from your (3DS employees, 
at least you Vincent) side and my counter-proposition is the occasion to 
exhibit a bit of democracy.

I propose the aforementioned solution using the year-based numbering for the 
release name (SCILAB_VERSION_STRING) and keeping the usual numbering 
SCI_VERSION_MAJOR.SCILAB_VERSION_MINOR.SCILAB_VERSION_MAINTENANCE with its 
actual signification. Please note that yo refer to Matlab and that this 
software uses this dual numbering system !

Users and developers who feel concerned with this subject can express 
themselves in this thread.

S.
---
Stephane Mottelet



Le 2023-02-17 18:12, COUVERT Vincent a écrit :

Hi Sylvain,

The semantic meaning of major/minor/patch version is kept:

-  Major releases may have API changes:

o   There may be API changes between Scilab 2023.m.p and 2024.m'.p' but it is 
not mandatory

-  Minor releases are API compatible:

o   Changes between Scilab 2023.m.p and Scilab 2023.m'.p' cannot be related API 
changes

-  Patches are binary compatible:

o   Changes between Scilab 2023.m.p and Scilab 2023.m.p' will not involve 
binary change. Changes on p (patch) mostly concern "hot fixes".



Compatibility with other tools (Matlab, Office, Excel, ...) and even OS 
following the same calendar will be easier to follow and understand.



This new release schedule also allows us to give a better visibility to 
developers/contributors in order to anticipate:

-  API changes,

-  Function deprecation,

-  Maintenance periods,

-  Scilab evolutions.

From a user perspective,  it will be easier to identify how

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-18 Thread Federico Miyara 


Stephane,

I have two concerns regarding the announcements. First, it may be confusing 
since users are accustomed to the legacy way of numbering versions, which is 
also the system most software packages use. The chaotic way Windows has 
numbered its versions (W 3.1, W 95/98, W 2000, Vista, W 7...) is an example of 
what shouldn't be done. I would prefer originality in the concept 
(functionality, UI, API), rather than version numbering.

Second, why limit the API changes to an annual periodicity? What if in the 
future many more developers work on the development of Scilab and it is 
possible to improve the API more than once a year?

Regards,

Federico Miyara


On 18/02/2023 12:30, Stephane Mottelet wrote:

Hello,

Please allow me to react to these answers as I feel also very concerned with 
this potential evolution. The year-base major number won't ease a better 
visibility about API changes. It will force us to systematically add a a notice 
saying  something like :

"Don't worry about the major version increase because this time there will not be 
any API change"

or its contrary :

"Unlike previous year, there will be major API changes in this new major version so 
you will have to upgrade your toolboxes".

Moreover, the rationale about the "compatibility with other tools (Matlab, Office, 
Excel, ...)" has no sense because these tools are commercial and closed source 
software. However, I admit that having the year information can be valuable for all users 
as it will allow to know immediately when a given version of Scilab was released.

The ideal scenario would be to use both systems: keep the usual not year-based 
major.minor.patch version numbering (SCI_VERSION_MAJOR, 
SCILAB_VERSION_MINOR,SCILAB_VERSION_MAINTENANCE in our headers) together with a 
release name (SCILAB_VERSION_STRING in our headers).

Presently Scilab is already ready for that since we have the following 
different outputs, for example here with a CI (continuous integration) build:

--> getversion
ans  =

 "scilab-mr3-0237210d"

--> getversion("scilab")
ans  =

  6.   1.   2.   1.677D+09

Here SCILAB_VERSION_STRING="scilab-mr3-0237210d" has been given during the CI 
and is completely arbitrary and not related to the second output which gives the true 
information about changes at the code level.

Having a new release schedule half-year based is completely independent of this need of version numbering. I 
am fine with the fact that you may need a kind of "branding" since almost all of the developers of 
Scilab are employed by a private entity who "owns" at least the "Scilab" name (but a big 
part of Scilab code owns to individual authors) to me that's the main rationale. However you should be aware 
that open-source software never completely belongs to its authors but also to its numerous users.

Since it beginnings Scilab had a complicated story and its governance has 
always been a mystery for most people using it. But in the last 5 years the 
huge work of promoting Scilab and keeping it alive and kicking was made by the 
users themselves. So, this proposed unilateral change from your (3DS employees, 
at least you Vincent) side and my counter-proposition is the occasion to 
exhibit a bit of democracy.

I propose the aforementioned solution using the year-based numbering for the 
release name (SCILAB_VERSION_STRING) and keeping the usual numbering 
SCI_VERSION_MAJOR.SCILAB_VERSION_MINOR.SCILAB_VERSION_MAINTENANCE with its 
actual signification. Please note that yo refer to Matlab and that this 
software uses this dual numbering system !

Users and developers who feel concerned with this subject can express 
themselves in this thread.

S.

---
Stephane Mottelet


Le 2023-02-17 18:12, COUVERT Vincent a écrit :

Hi Sylvain,

The semantic meaning of major/minor/patch version is kept:

-  Major releases may have API changes:

o   There may be API changes between Scilab 2023.m.p and 2024.m'.p' but it is 
not mandatory

-  Minor releases are API compatible:

o   Changes between Scilab 2023.m.p and Scilab 2023.m'.p' cannot be related API 
changes

-  Patches are binary compatible:

o   Changes between Scilab 2023.m.p and Scilab 2023.m.p' will not involve binary change. 
Changes on p (patch) mostly concern "hot fixes".



Compatibility with other tools (Matlab, Office, Excel, ...) and even OS 
following the same calendar will be easier to follow and understand.



This new release schedule also allows us to give a better visibility to 
developers/contributors in order to anticipate:

-  API changes,

-  Function deprecation,

-  Maintenance periods,

-  Scilab evolutions.


From a user perspective,  it will be easier to identify how up-to-date or 
deprecated their Scilab could be.


Vincent



From: dev  
On Behalf Of Sylvain Corlay
Sent: Friday, February 17, 2023 4:04 PM
To: List dedicated to the development of Scilab

Re: [Scilab-users] [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit support

2023-02-18 Thread Stephane Mottelet 

Hello,

Please allow me to react to these answers as I feel also very concerned with 
this potential evolution. The year-base major number won't ease a better 
visibility about API changes. It will force us to systematically add a a notice 
saying  something like :

"Don't worry about the major version increase because this time there will not be 
any API change"

or its contrary :

"Unlike previous year, there will be major API changes in this new major version so 
you will have to upgrade your toolboxes".

Moreover, the rationale about the "compatibility with other tools (Matlab, Office, 
Excel, ...)" has no sense because these tools are commercial and closed source 
software. However, I admit that having the year information can be valuable for all users 
as it will allow to know immediately when a given version of Scilab was released.

The ideal scenario would be to use both systems: keep the usual not year-based 
major.minor.patch version numbering (SCI_VERSION_MAJOR, 
SCILAB_VERSION_MINOR,SCILAB_VERSION_MAINTENANCE in our headers) together with a 
release name (SCILAB_VERSION_STRING in our headers).

Presently Scilab is already ready for that since we have the following 
different outputs, for example here with a CI (continuous integration) build:

--> getversion
ans  =

 "scilab-mr3-0237210d"

--> getversion("scilab")
ans  =

  6.   1.   2.   1.677D+09

Here SCILAB_VERSION_STRING="scilab-mr3-0237210d" has been given during the CI 
and is completely arbitrary and not related to the second output which gives the true 
information about changes at the code level.

Having a new release schedule half-year based is completely independent of this need of version numbering. I 
am fine with the fact that you may need a kind of "branding" since almost all of the developers of 
Scilab are employed by a private entity who "owns" at least the "Scilab" name (but a big 
part of Scilab code owns to individual authors) to me that's the main rationale. However you should be aware 
that open-source software never completely belongs to its authors but also to its numerous users.

Since it beginnings Scilab had a complicated story and its governance has 
always been a mystery for most people using it. But in the last 5 years the 
huge work of promoting Scilab and keeping it alive and kicking was made by the 
users themselves. So, this proposed unilateral change from your (3DS employees, 
at least you Vincent) side and my counter-proposition is the occasion to 
exhibit a bit of democracy.

I propose the aforementioned solution using the year-based numbering for the 
release name (SCILAB_VERSION_STRING) and keeping the usual numbering 
SCI_VERSION_MAJOR.SCILAB_VERSION_MINOR.SCILAB_VERSION_MAINTENANCE with its 
actual signification. Please note that yo refer to Matlab and that this 
software uses this dual numbering system !

Users and developers who feel concerned with this subject can express 
themselves in this thread.

S.

---
Stephane Mottelet


Le 2023-02-17 18:12, COUVERT Vincent a écrit :

Hi Sylvain,

The semantic meaning of major/minor/patch version is kept:

-  Major releases may have API changes:

o   There may be API changes between Scilab 2023.m.p and 2024.m'.p' but it is 
not mandatory

-  Minor releases are API compatible:

o   Changes between Scilab 2023.m.p and Scilab 2023.m'.p' cannot be related API 
changes

-  Patches are binary compatible:

o   Changes between Scilab 2023.m.p and Scilab 2023.m.p' will not involve binary change. 
Changes on p (patch) mostly concern "hot fixes".



Compatibility with other tools (Matlab, Office, Excel, ...) and even OS 
following the same calendar will be easier to follow and understand.



This new release schedule also allows us to give a better visibility to 
developers/contributors in order to anticipate:

-  API changes,

-  Function deprecation,

-  Maintenance periods,

-  Scilab evolutions.


From a user perspective,  it will be easier to identify how up-to-date or 
deprecated their Scilab could be.


Vincent



From: dev  On Behalf Of Sylvain Corlay
Sent: Friday, February 17, 2023 4:04 PM
To: List dedicated to the development of Scilab 
Subject: Re: [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit 
support



Hi Vincent,



The problem with year-based versioning is that it removes any semantic meaning 
to minor and patch - especially with respect to relinking etc. What are the 
expected benefits of the proposed change ?



Best,







On Fri, Feb 17, 2023 at 4:01 PM COUVERT Vincent 
mailto:vincent.couv...@3ds.com>> wrote:

Hi Sylvain,



Thanks for your email, we completely agree with you about the meaning and 
contents of major, minor and patch versions.



As you say, "Major version updates may break API compatibility" but it is not 
mandatory for a major version.

As in the past, we will try to not break compatibility between versions 
(whatever the version type is) but if we have to do