New stable release

New stable release

Postby Robert » Tue Mar 07, 2017 8:31 pm

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

Re: New stable release

Postby DGDanforth » Wed Mar 08, 2017 7:20 pm

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

Re: New stable release

Postby Josef Templ » Thu Mar 09, 2017 3:26 pm

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

Re: New stable release

Postby Robert » Thu Mar 09, 2017 8:11 pm

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

Re: New stable release

Postby DGDanforth » Thu Mar 09, 2017 11:19 pm

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

Re: New stable release

Postby Ivan Denisov » Fri Mar 10, 2017 6:49 am

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

Re: New stable release

Postby Robert » Fri Mar 10, 2017 7:39 am

I would support Ivan's plan - of course we would react to any major new bugs found.
User avatar
Robert
 
Posts: 987
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: New stable release

Postby Josef Templ » Fri Mar 10, 2017 8:40 am

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

Re: New stable release

Postby Ivan Denisov » Fri Mar 10, 2017 10:43 am

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: 1694
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: New stable release

Postby Ivan Denisov » Fri Apr 14, 2017 4:33 am

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

Next

Return to Infrastructure

Who is online

Users browsing this forum: No registered users and 1 guest

cron