Re: Confusion over builds.

[James Hale]

Hi Richmond,
Sorry about the confusion, Peter was very quick to remove the entries I had 
referred to.

As for leaving things, you are a bit confused. The versions I referred to were 
in fact "milestones" on GitHub. I was making no comment at all on the download 
page only the  work in progress pages of GitHub.

However Peter's post offered a complete picture of how they are trying to 
manage these items and clarified, somewhat, my concerns and questions.

James

> I honestly don't know what you are talking about. Here:
> 
> http://downloads.livecode.com/livecode/
> 
> I can see 8.0.1 STABLE  and 8.1.0 RC1
> 
> So, there is no "8.0.2" and no "8.10"
> 
> Over in GitHub things are, by the nature of GitHub, likely to be 
> somewhat more confusing.
> 
> This is one of the main reasons when I want to find out the way the 
> numbering of Livecode
> releases is going I stick to the download page.
> 
> Certainly, I can see that one could, carelessly, mistake "8.1.0" for 
> "8.10", but, then, things are always
> worth a second look.
> 
> "start with removing those builds that are actually released"
> 
> No, let's NOT, and let's use them as the road-map, and not the others: 
> otherwise we'd still all
> be sitting around waiting for Hypercard 3.0.

___
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

Re: Confusion over builds.

[James Hale]

Thanks for the explanation Peter.

James

___
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

Re: Confusion over builds.

[RM]

I honestly don't know what you are talking about. Here:

http://downloads.livecode.com/livecode/

I can see 8.0.1 STABLE  and 8.1.0 RC1

So, there is no "8.0.2" and no "8.10"

Over in GitHub things are, by the nature of GitHub, likely to be 
somewhat more confusing.


This is one of the main reasons when I want to find out the way the 
numbering of Livecode

releases is going I stick to the download page.

Certainly, I can see that one could, carelessly, mistake "8.1.0" for 
"8.10", but, then, things are always

worth a second look.

"start with removing those builds that are actually released"

No, let's NOT, and let's use them as the road-map, and not the others: 
otherwise we'd still all

be sitting around waiting for Hypercard 3.0.

My computers (that means about 4 of the things) and my external 
hard-disks are littered with
oddly numbered versions of my Devawriter Pro; some of them did lead to 
releases; most of them
are where I went off on some "very clever tangent" which turned out to 
be a big mistake.


I would suppose most people have similar situations, unless, unlike me, 
they have the self-discipline
to purge their systems of all those "also rans". This is a bit like 
evolution; the man with teeth in his bottom
died out (right organ, wrong end of the body); or, if you are a 
creationist; please do not tell me that God
didn't fool around with ideas that seemed extremely good on day 4, but 
looked pretty awful on the morning of day 5.

After all, we are, supposedly, made in his own image :-)

GitHub is the land of possibilities; and 'tis a marvellous place; but 
not for the nervous.


Richmond.

On 24.05.2016 17: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?

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.

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

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?

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.

James

___
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



___
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

Re: 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  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 
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

Re: Confusion over builds.

[James Hale]

Well someone was quick.

;-)

___
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