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 <busin...@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.br...@livecode.com>
LiveCode Open Source Team
LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
