[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release Plans
From: |
Michael D. Godfrey |
Subject: |
Re: Release Plans |
Date: |
Thu, 26 Sep 2013 13:58:43 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 |
On 09/26/2013 01:27 PM, Rik wrote:
That said, we have an enormous backlog of good features which need to get
out. I always thought that we were going to do an intermediate 3.8 release
anyways so I will put that forward again. Why not do a quick release now,
which still treats the GUI as experimental, and a 4.0 release whenever
JHandles have been incorporated?
--Rik
I very much agree that releasing "buggy" software is a very bad idea.
But, frequent
releases do not need to imply "buggy." In fact, it is my experience
that frequent
releases are key to effective bug reduction. A long period between
releases means
that latent bugs hang around and are only caught after the release.
These are hard
to resolve since the code containing the bug may have been written, and
believed to
be correct, a log time ago. Users find bugs that testing never catches.
In my previous email I think I suggested that the GUI, as it is now,
should not be the
default, and, as Rik says, should be described as "experimental." I
also think that the
JIT should be compiled in but be default off. I have used it quite a
lot in the context of
mixed complex and real arrays and have used the loop-length parameter to
set the
minimum loop to a low value. My experience is that it all works
correctly, and that
a low loop value does not add significant overhead. All the same, JIT
has not had sufficient
exposure to justify having it on by default.
So, I agree with Rik. An "immediate" release is a VERY good idea and
calling it 3.8
saves the level 4.0 for the "big" release of the completed GUI. As part
of the 3.8
release users should be strongly encouraged to try the GUI and report
their experience,
both bugs and ease-of-use items. So, the next steps are, obviously, a
feature
freeze date and a blocking bug list. I would prefer the freeze date to
be something like
2 weeks away, or even now. I am aware of only a few items that need
clean up before
the freeze and start of release candidate releases.
Michael
- Re: Release Plans, John W. Eaton, 2013/09/25
- Re: Release Plans, Rik, 2013/09/26
- Re: Release Plans, Benjamin Abbott, 2013/09/26
- Re: Release Plans,
Michael D. Godfrey <=
- Re: Release Plans, John W. Eaton, 2013/09/26
- Re: Release Plans, Michael D. Godfrey, 2013/09/26
- Re: Release Plans, John W. Eaton, 2013/09/26
- Re: Release Plans, Michael D. Godfrey, 2013/09/26
- Re: Release Plans, c., 2013/09/26
- Re: Release Plans, Rik, 2013/09/26
- Re: Release Plans, Ben Abbott, 2013/09/26
- Re: Release Plans, Daniel J Sebald, 2013/09/29
- Re: Release Plans, Robert T. Short, 2013/09/29
- Re: Release Plans, Ben Abbott, 2013/09/29