New stable release

User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

New stable release

Post 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?
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: New stable release

Post 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
User avatar
Josef Templ
Posts: 2045
Joined: Tue Sep 17, 2013 6:50 am

Re: New stable release

Post 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
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: New stable release

Post 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.
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: New stable release

Post 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.
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: New stable release

Post 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.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: New stable release

Post by Robert »

I would support Ivan's plan - of course we would react to any major new bugs found.
User avatar
Josef Templ
Posts: 2045
Joined: Tue Sep 17, 2013 6:50 am

Re: New stable release

Post 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
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: New stable release

Post 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.
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: New stable release

Post 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.
Post Reply