Page 1 of 4

New stable release

Posted: Tue Mar 07, 2017 8:31 pm
by Robert
It is six months (almost!) since 1.7 stable, and we have some significant improvements available (eg disassembler, hierarchical menus), so I think it is time for a new stable release. Ivan has also already suggested this.

What do other people think?

Re: New stable release

Posted: Wed Mar 08, 2017 7:20 pm
by DGDanforth
Robert wrote:It is six months (almost!) since 1.7 stable, and we have some significant improvements available (eg disassembler, hierarchical menus), so I think it is time for a new stable release. Ivan has also already suggested this.

What do other people think?
Sounds good.

Should we have an agreed upon waiting period from the last change
before saying it is stable?

Hypothetically, IF we knew how many people access a changed feature
THEN we could set a number for the minimum accesses before the
feature is deemed stable (as long as there were no bugs detected).

-Doug

Re: New stable release

Posted: Thu Mar 09, 2017 3:26 pm
by Josef Templ
With the newly discovered bug in Kernel.Upper/Lower I would agree that
a new version should be released. Otherwise I wouldn't see much need.
A new version adds a lot of work and waiting time, at least if we follow the
standard process of going to beta and then to release candidate and then to release.

There is an open docu-topic raised by Helmut, which would be easy to do.

There are some details in DevSearch (hard coded string, etc.)
that I would like to fix before going beta.

There are also some pending changes on issue-#142 (decoder).
The changes are ready for review and voting.

- Josef

Re: New stable release

Posted: Thu Mar 09, 2017 8:11 pm
by Robert
Josef Templ wrote:A new version adds a lot of work and waiting time, at least if we follow the
standard process of going to beta and then to release candidate and then to release.
I am currently close to updating, "freezing", & publishing a large body of (non Center) material.
I would like to avoid using obsolete facilities (eg CpcDropDown), but want this material to be compatible with a "stable" version of BlackBox.
My customers would not like the idea of updating to use something called "unstable".

So I wonder if it is realistic to have a new version in 4 (at most 6) weeks?

I don't fully understand our release process, but if it really is "a lot of work and waiting time" I wonder if all this work is valued-added, and if maybe the process would benefit from being streamlined. I suspect that there is not a large body of users who will specially install a release candidate to give it extensive field testing.

Re: New stable release

Posted: Thu Mar 09, 2017 11:19 pm
by DGDanforth
Perhaps we need a suite of programs that exercise all of the procedures
in BlackBox. They would need to have agreed upon post states that can be measured.

That is a very, very big task, I would be similar to having a semantic GitHub.

Re: New stable release

Posted: Fri Mar 10, 2017 6:49 am
by Ivan Denisov
This version 1.7.1 is patch version, so I think, that we should switch to beta now. After all pending votes pass we should switch to RC and in 6 weeks is possible to have 1.7.1 final.

Re: New stable release

Posted: Fri Mar 10, 2017 7:39 am
by Robert
I would support Ivan's plan - of course we would react to any major new bugs found.

Re: New stable release

Posted: Fri Mar 10, 2017 8:40 am
by Josef Templ
Robert wrote:
Josef Templ wrote:A new version adds a lot of work and waiting time, at least if we follow the
standard process of going to beta and then to release candidate and then to release.
I am currently close to updating, "freezing", & publishing a large body of (non Center) material.
I would like to avoid using obsolete facilities (eg CpcDropDown), but want this material to be compatible with a "stable" version of BlackBox.
My customers would not like the idea of updating to use something called "unstable".

So I wonder if it is realistic to have a new version in 4 (at most 6) weeks?

I don't fully understand our release process, but if it really is "a lot of work and waiting time" I wonder if all this work is valued-added, and if maybe the process would benefit from being streamlined. I suspect that there is not a large body of users who will specially install a release candidate to give it extensive field testing.
Technically, it is possible to do a new stable release in a few minutes.
The normal flow however, would be to first declare it feature complete and ready for external testing, i.e. beta.
When the beta version looks fine after some testing the state is advanced to "release candidate".
And if the release candidate does not show problems there is a "stable" release.
This is all about testing by a community as large as possible. After all, a "stable" release should
deserve its name. Otherwise it is just a tag put onto a release.
If there are many changes during this testing phase, the testing must be repeated and then it takes longer
or it is not done at all.
In general, the process must be such that it works for us. It does not give sense to define a process and
then cheat it.

I agree that 1.7.1 is a small release in the sense that it has only simple changes and the testing time
can be limited of course. 4 weeks are certainly possible.

With the Kernel.Upper/Lower bug not fixed it is irresponsible to go to beta.
Why? We give a system to external testers where we know that it can crash by
ordinary Strings.Upper calls. It is better to fix this first and then switch to beta.
There is no reason to delay this fix. Please look at it.
Planning to fix this later (during beta or after beta) is cheating the process, I think.

- Josef

Re: New stable release

Posted: Fri Mar 10, 2017 10:43 am
by Ivan Denisov
I agree with Josef, strange to give the beta with bugs to people for testing. Let's finish pending features and bugs, then switch to beta end test beta by our selfs intensively for a week and then switch to RC.

Re: New stable release

Posted: Fri Apr 14, 2017 4:33 am
by Ivan Denisov
I am suggesting to add stacks manipulations support and release beta for 1.7.1. IMHO, Coroutines and Console can be kept for 1.8.