Release criteria (was "Release 6.7.7 / 7.1.0")

[Sebastien Nouat]

On 24/09/2015 22:11, Richard Gaskin wrote:
> Sebastien Nouat wrote:
>
> > By "Stable", we mean that no reported regressions have been
> > introduced in 6.7.7 / 7.1.0, compared to the previous Stable
> > release.
>
> Which regressions count?
> Respectfully, a frequent concern cited here, in my local user group, 
> in the forums, and elsewhere is the number of regressions outstanding 
> in LiveCode across multiple versions.
>
> Just thinking back on my own reports over the last year, it may be 
> that a majority of them are for things that had worked in previous 
> versions.  Since they were reported we've seen "Stable" release after 
> "Stable" release, yet these regressions remain.
I think that the best way to picture it is that there have been huge 
amount of changes brought first in LiveCode 6.7 with the update to 
Cocoa, and in LiveCode 7, with the complete refactoring of the engine, 
in preparation for LiveCode 8.

Those massive changes changes also brought in their numbers of 
regressions - that's how we call a bug that has been introduced in a new 
version and is breaking something that used to work.

Now, every maintenance release (6.7.x and 7.1.y) is mainly fixing those 
regressions introduced in 6.7.7 DP 1 and 7.1.0 DP 1, that we can simply 
call initial regressions.

However, each maintenance cycle only sees initial regressions (and older 
bugs) fixed in the first RC. After that first RC, new RCs come to make 
sure that none of the initial regression / bug fixes that we made brings 
in any regression. When we are sure that no regression has been 
introduced by any of the fixes for this maintenance cycle, then we label 
the maintenance release as Stable.
>
> We know that sometimes a build is pushed from "DP" to "Stable" to take 
> care of Apple's lack of backward compatibility with regard to building 
> for iOS.
>
> But beyond accommodating that, it would be helpful if the team could 
> clarify the drivers behind moving a release to "Stable" with such a 
> range of confirmed issues.

Each new maintenance, Stable release, is simply more stable than the 
previous Stable release. The terminology Stable is maybe not adapted; 
but the day we announced the release of a GM release (following the 
naming, for instance, of Apple products - they are never called 
"Stable"), it brought more confusion than clearness amongst the list 
users. We could potentially use a label different from "Stable" for the 
last, public release of each maintenance cycle though.
>
> The general sentiment I hear is that most folks wouldn't mind waiting 
> a bit longer between releases to see more confirmed issues addressed. 
> Given the expense of building a release, maybe that would benefit the 
> company as well?
>

It's been 2 months and a half since we released 6.7.7 RC 1 / 7.1.0 DP 1. 
The next versions, 6.7.8 and 7.1.1, will have a fair amount of initial 
regressions / bugs fixes.


Warm regards,

-- 
Sébastien Nouat
LiveCode Development Team