<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
My thoughts on releases. I agree that releases have been
incredibly slow, but haven't spent time bickering about it.
Instead, I'm pleased when releases are finally here. I've wondered
about the organization(s) behind Scilab. It seems we get a new
release every time Scilab is reorganized in some way ... and that
there's lots of political stuff going on.<br>
<br>
I hope that the Scilab 6 milestone means that Scilab (as in the
software itself) is organized in a way suitable for the next many
years. Hereby I imply that any 6.X release only has to reflect
incremental (and preferably backwards compatible) improvements.<br>
<br>
Personally I consider "nightly builds" to be bleeding edge, for
developers, and not something I can use for my development - just
as I cannot distribute Scilab code and reference a nightly-build
version of Scilab to whoever might be interested.<br>
<br>
>each publication needs or deserves some specific tasks that
take time<br>
<br>
Yes, typically minimized by writing a developer-oriented "how-to"
release (aka to-do list).<br>
<br>
IMHO regarding release frequency, the second-most important reason
to release is so that the project appears alive and not dead.<br>
<br>
Best regards,<br>
Claus<br>
<br>
On 10-04-2017 13:58, Samuel Gougeon wrote:<br>
</div>
<blockquote cite="mid:ee317e22-d63a-2a22-d4c1-d97b0b789579@free.fr"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hello,<br>
<br>
I am redirecting this discussion on users@ because it shall
mainly interest most of users, while, after 2 weeks, palpably
not developers:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mailinglists.scilab.org/Scilab-release-frequency-tt4035908.html">http://mailinglists.scilab.org/Scilab-release-frequency-tt4035908.html</a><br>
<br>
On 21/03/2017 à 15:18, Clément David wrote on dev@:<br>
</div>
<blockquote cite="mid:1490105889.31706.16.camel@esi-group.com"
type="cite">
<pre wrap="">After some private discussion by direct mail, Samuel pointed that I have to open the discussion to ask for your needs / advises for the release frequency ; thanks Samuel for that. Please find also attached a Scilab version timeline for reference.
To clarify the discussion, I will use the convention major.minor.revision (6.0.0 == 6 major, 0 minor, 0 revision) where :
* a revision only contains bug fixes and should be script compatible but might deprecate functions
* a minor version remove deprecated functions
* a major version is a Scilab partial rewrite
IMHO an expected (with no strict application) period should be :
* 6-9 months “revision” cycle
* 18-24 months “minor” cycle (2 to 3 revisions)
* much more for a “major”
Do you have an opinion on the Scilab release period ? Which period will simplify your developments ?</pre>
</blockquote>
<br>
In private, Clément's rationale is, mainly and AFAIU, that
preparing the publication of each release takes some time: There
is a list of things to do, like formating the release notes,
publishing new online help pages, updating download pages in
several languages, etc. Then, this time is not used for
developments.<br>
<br>
I was asking about the intentions of the Scilab team about the
future release frequency, because i thought -- and still think --
that roughtly 2 years between 2 consecutive minor releases is
incredibly long at the usual Information Technologies timescale.<br>
<font color="#3333ff">Keeping such a slow rate would mean that we
would have to wait up to 2 years between the inclusion of a new
feature in Scilab, and its distribution in an official Scilab
release!</font> So to wait even longer between the
implementation of any new feature, and its actual availability in
Scilab. Even for the "smallest" features, as soon as they are new.<br>
<br>
Obviously, we can't ignore that each publication needs or deserves
some specific tasks that take time, and that this time should be
minimized.<br>
Moreover, we may note that contrarily to many free and open
softwares, <font color="#3333ff">nighly built releases are
available online for Scilab, mostly at every moment</font>. From
time to time, there are some short dead periods in these daily
releases in which the most recently included features are
available. These binary releases can be installed and used out of
the box like every "official" release, without uninstalling the
current "official" release from our computer. Actually, <font
color="#3333ff">installing a new Scilab version never requires
uninstalling other (even multiple) versions of Scilab on the
same computer</font>. Everyone can have as many Scilab versions
installed on the same computer as wished, whitout any problem. It
takes less than 5 mn to install a new Scilab. And add some
additional 5-15 mn to reset our Preferences, install few ATOMS
modules for it, etc.<br>
This is very great and useful and safe.<br>
<br>
So, after our last email, i came to the following conclusion: In
my opinion, <font color="#3333ff">publishing revision 6.n.X
releases is useless</font>. For the future, we could expect <br>
<ul>
<li>The publication only of official minor versions: 6.X<br>
This should allow publishing them at a faster rate, <font
color="#3333ff">at least once per year</font>, never less.<br>
<br>
</li>
<li>Keeping Nightly built (daily) releases for the <font
color="#3333ff">current 6.X+ branch</font>, in which bugs
are fixed "on-the-fly", the documentation is improved, and all
other safe daily modifications are included and available on
download the day after.<br>
<br>
</li>
<li>Keeping Nightly built (daily) releases of the <font
color="#3333ff">master preparing the 6.(X+1) release</font>,
in which new features or modifications that could make Scilab
unstable are progressively included.<br>
</li>
</ul>
Hence, the publication process would take less time ; new features
would become available in the year instead of in a 2-year period ;
and Scilab's safety will be unchanged.<br>
<br>
Hope reading other contributions and thoughts,<br>
<br>
Best regards<br>
Samuel<br>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org">users@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/users">http://lists.scilab.org/mailman/listinfo/users</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>