Hello,
Le 16/02/2023 à 16:42, COUVERT Vincent a écrit :
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…
That's great to know that opportunities to add extensions of existing features
or new features will be reviewed much more frequently. I asked for this through
this mailing list for years now. So i applause.
About numbering of so-called major versions: the only critics i could address
is the shift in year for october releases. Numbering 2024 a release published
in 2023 looks cryptic to me. Otherwise, i see two main advantages for this
proposal:
* year-based numbers are clearly user oriented. M.m.p stuff is from devs and
mainly for devs. While having a unique referential -- since the gregorian
calendar spread over the planet (it made more than 300 years to be the case..)
- is for everyone and for everything. I was not really aware that year-based
numbers is the preference of more and more commercial enterprises. They know
that their business relies first on their users / customers. Unfortunately,
this is less clear in the open source domain. And that's a pity.
Now, for Scilab, obsolescences and forthcoming features will be announced in
advance in release notes and in the related documentation directly with the
targeted year. No need to make some uncertain hypotheses about the rate of
forthcoming releases and their type patch or minor. The announced year will
tell it directly, and will be clear, as a countdown, with no double numbering.
* Because of this shared and directly visible time referential, a year-based
index should improves interoperability.
* Interoperability with other softwares : when we want to import an excel
file in Scilab, then the year of the excel format matters. Reversely, if
someone wants to call Scilab in some external environment, the Scilab Major
year could matter as well, and will be more easily tested as a number than as a
string.
* Interoperability between Scilab and ATOMS external modules, whose
numbering could also be addressed. The versioning and maintenance of ATOMS
modules is a major topic by its own.
As the author of the module named removed, that aims to gather all pages of all
former removed functions and features, and that lists them by Scilab version
numbers where they could be used the last time, i can say that doing this list
shown that neither releases notes, nor obsolescence announced (or not) in the
documentation pages were up to now fully reliable. For instance a subset of
functions was removed in Scilab 6.0.0 without any announcement. Sometimes there
were removals not at the announced version. Sometimes some obsolescence and
removed are announced but are not done (and the announce is not updated).
Sometimes the code is removed, but not the related help pages! Still in 6.1.1,
try
--> help isequalbitwise // you get the page
--> isequalbitwise
Undefined variable: isequalbitwise
The function was removed in 6.0.0. The discrepancy between the available page
for no remaining function was reported very soon after 6.0.0. But for 5 years,
nothing was done to clarify this.
After working --sometimes hard -- for Scilab for more than 8 years now, i can
say that i am sure that this kind of thing is definitely not related to how
releases are numbered, but how the Scilab forge is managed.
Best regards
Samuel
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/
_______________________________________________
users mailing list - users@lists.scilab.org
Click here to unsubscribe: <mailto:users-unsubscr...@lists.scilab.org>
https://lists.scilab.org/mailman/listinfo/users
