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
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
