Confusion over builds.

[Peter TB Brett]

On 24/05/2016 15:24, James Hale wrote:
> Now that 8 is out,things on GitHub should be simpler, right? No, not
> really. We still have 8.01rc1 sitting there. We have 802rc1 sitting
> there. 8.10dp1 AND 8.10dp2 AND 8.10 future?

It's just because I didn't close the milestones yet.  Consider the
milestones on GitHub to be informative, rather than normative.

At the moment, the next release in the stable branch of LiveCode (i.e.
8.0.x) will be 8.0.1.  Then, after that, the next stable release will be 
8.0.2-rc-1.

There is no 8.0.1 milestone in GitHub because no-one has found any 
regressions in 8.0.1-rc-1 relative to the previous stable release 
(8.0.0) so there have been no pull requests to it.

> While I really like the action happening I wish we could collapse
> things a bit and get the different branches consistent. For instance
> let's start with removing those builds that are actually released.

You mean milestones.  I now have.  Thank you for pointing it out.

> That would leave us with 8.02rc1, 8.1dp2 and 8.10 future (whatever
> this is supposed to mean).

The 8.1.0-future milestone in the livecode-ide repository is used only
for GitHub issues (which we're probably not going to continue to use).
It is a milestone used for grouping issues which are probably not urgent 
to fix, but maybe could be addressed at a future point in the LiveCode 
8.1 development cycle.

> Then could be get some guidance as to whether 8.1 contains the fixes
> in 8.02 or not. In other words, if 8.02 fixes something we wanted
> fixed but we also want to test against 8.1, can we count on not
> having worry about a missing fix?

We (i.e. usually Ali, Panos or I) periodically merge the develop-8.0 
branch (which will be used to release 8.0.2-rc-1) into the develop 
branch (which will be used to release 8.1.0-dp-2).  If a fix released 
in, say, 8.0.2-rc-1, then the fix will be guaranteed to appear in all 
subsequent 8.0.x and 8.1.x releases.

Because of the stable branch stabilisation cycle, there will 
occasionally be times when a fix destined for stable is released in an 
unstable branch DP first.

> Which gets me to my main hope. Could we perhaps release the rc' a bit
> more frequently? I mean there was only one rc for 8.01 and now we are
> already almost up to 8.02rc1 but before it was released we get an
> 8.1dp1. Can't you move the unfinished bits of 8.02rc1 into a future
> 8.02rc2 and get 8.02rc1 out? Will there be an 8.02rc2 or will you
> jump to 8.03rc1? Sort makes the 'rc' labels superfluous.

In the stable branch, the dev team always makes at least one RC release 
to make sure that the subsequent final release is regression-free.  When 
there are no regressions found, it's okay to make the final release 
immediately.  Otherwise, it's necessary to fix the regressions (and 
_only_ the regressions) and make additional RC releases.

This helps to make sure that the stable releases really are stable. 
When bugs are fixed correctly, there aren't any regressions, so there 
will be exactly one RC release.  This is optimum.

It's incorrect to release anything that's "unfinished" in an RC1 because 
a release candidate is supposed to be a release candidate.  Bug fixes 
that don't make it into a stable RC1 release will wait until the next RC1.

At the moment I expect that 8.0.1 GM will be released this afternoon, 
and 8.0.2 RC 1 will be released in the next 7-10 days, depending on the 
development team schedule.  At the moment I am aiming for a minimum 
release rate of one stable and one unstable release per two weeks.

There is a cost to making releases, and the dev team needs to balance 
spending time on making releases with the many other tasks we're 
expected to do.

If you need builds outside the normal release process then there are two 
options:

- you can compile your own Community engines

- you can contact <business at livecode.com> for access to our internal 
staging server with candidate builds of Community, Indy and Business 
editions (some of our Business subscribers find this service useful, but 
note that these builds are "use at your own risk")

For more detailed information on how branches in GitHub relate to the 
release cycle, see 
https://github.com/livecode/livecode/blob/develop/docs/release_branching_policy.md

                                       Peter

-- 
Dr Peter Brett <peter.brett at livecode.com>
LiveCode Open Source Team

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/