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 <[email protected]> On Behalf Of Sylvain Corlay
Sent: Friday, February 17, 2023 4:04 PM
To: List dedicated to the development of Scilab <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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 it, we will do it in major
versions (planned for October) and try to warn users asap.
Best regards,
Vincent
From: dev <[email protected]<mailto:[email protected]>>
On Behalf Of Sylvain Corlay
Sent: Thursday, February 16, 2023 4:57 PM
To: List dedicated to the development of Scilab
<[email protected]<mailto:[email protected]>>
Subject: Re: [Scilab-Dev] Scilab releases schedule / End of Windows 32-bit
support
Hi Vincent,
Thank you for the updates and the new releases.
I think that one potential issue with such a versioning scheme is the
communication of backward compatibility of APIs and ABIs. A commonly accepted
schemas is to have Major.major.patch schema where,
1. Patch version updates are binary compatible
This means that if you built B and linked with A version M.m.x, you can install A
version M.m.y with y>=x without any issue.
2. Minor version updates are API compatible
This means that you can rebuild B without changing its code against the new
version of A.
2. Major version updates may break API compatibility
This means that you may need to update the code of B if you make use of APIs of
A.
Year-based versioning prevents making deductions based on the version number.
While it may be possible to infer such information based on sonames, the
semantics of sonames are platform dependent (incompatible between OS X and
Linux), and very easy to get wrong.
Conda-forge makes heavy use of the M.m.p pattern, especially in the
"run_exports" mechanism which allows it to have a working rolling distribution.
Best,
Sylvain
On Thu, Feb 16, 2023 at 4:42 PM COUVERT Vincent
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
Scilab operational team and contributors are working hard on next release of
Scilab that will be available in the next weeks.
In the future, we will follow a new 6-month release schedule and use a new
release numbering system X.Y.Z based on years:
- 2023.0.0 very soon (as we did not release a version in October 2022)
- 2023.1.0 in May 2023
- 2024.0.0 in October 2023
- 2024.1.0 in May 2024
- And so on...
Minor versions will be released as needed between these planned versions and will only
contain "hot fixes" with no new features, no function prototype change, ...
Releasing Scilab X.2.Z will probably never happen but remains possible.
Since we no more have hardware resources to validate it, we will not release a
32-bit version of future Scilab releases for Windows (Linux 32-bit versions are
no more available since Scilab 6.0.0).
Best regards,
Scilab operational team
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/
_______________________________________________
dev mailing list
[email protected]<mailto:[email protected]>
https://lists.scilab.org/mailman/listinfo/dev
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/
_______________________________________________
dev mailing list
[email protected]<mailto:[email protected]>
https://lists.scilab.org/mailman/listinfo/dev
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/
_______________________________________________
dev mailing list
[email protected]<mailto:[email protected]>
https://lists.scilab.org/mailman/listinfo/dev
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/
_______________________________________________
dev mailing list
[email protected]
https://lists.scilab.org/mailman/listinfo/dev
