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