What happened to LC version numbers?
mark at livecode.com
Wed Jul 19 16:33:48 CEST 2017
On 2017-07-19 15:54, Bob Hall via use-livecode wrote:
>> On Jul 19, 2017, at 4:55 AM, Mark Waddingham via use-livecode
>> <use-livecode at lists.runrev.com> wrote:
>> Admittedly, this was perhaps a slightly riskier test then something
>> like the handler menu;
> Why are we testing a new feature in a RELEASE CANDIDATE version #2?
To support our user-testing efforts.
> Why are significant features being added at all to the 8.x branch?
To support our user-testing efforts.
> What standard (if any) do Livecode version numbers follow?
Semver with an explicit distinction between dp/rc/gm and iterations
> So, here’s to looking forward to 8.2.0dp1 (which will be known as
> 8.1.6rc3 in the real world :-)
We need to iterate quickly on changes to the first run experience to
LiveCode to ensure that we are doing all we can to attract new users to
the platform. This has to encompass the entire flow which users see from
finding us on the web, through to looking through the website, getting
an account and activating the product. In essence, it has to be done
'live' as otherwise we risk not getting reasonable nor accurate results
on which we can base further work.
So we cannot do this from develop (i.e. 9.x) as that is *not* what
people get when they follow through this process - they get the 'most
recent stable version' which is 8.1.x. Furthermore, the turnaround on
DPs on develop is quite long - for all kinds of reasons. Indeed we wish
it were quicker, but at present there is simply no way we can make that
happen. Thus, we took the decision to do it against the stable line -
New users (coming through our website) now actually get the latest RC of
the stable line (8.1.x) when they download.
Iterations on the first run experience is being done in the RC's of the
stable line (8.1.x) simply because we can turn them around relatively
quickly (in comparison to 9 DPs).
The changes we are making are almost exclusively IDE changes, and the
majority of those exclusive to what you see when you are in 'first run'
mode - which is something which (usually) only new users see (beyond the
slight issue with the backdrop change in 8.1.6-RC-2 - we'll certainly
try harder to make sure a similar thing like that does not happen in
So, in essence, we are using RCs as 'mini DPs' for very focused sets of
changes that we are testing with direct input from *real* potential new
We will still not release an 8.1.x GM until we are happy any changes in
them are suitable, and of sufficient quality - indeed, any 'failed'
experiments in this regard will not make it to GM.
The downside for existing users is that it might take a little more
iteration on 8.1.x releases to get them to GM (and some RC's *might* -
due to the fact human's are, well, human - have the occasional 'bump').
The upside for existing users two-fold:
1) Some of these changes are not entirely tied to first run (e.g.
handler menu) and hopefully are useful additions to IDE usability for
everyone (should they want to use them - hence the hold preferences
related thread recently).
2) If this process works then the growth of our community will
We have discussed internally being able to make the 'first run
experience' pluggable so we can do this kind of thing *outside* of any
particular release. However, realistically, that is a significant
project in its own right, and some of the changes we are evaluating
(based directly on feedback) do need to 'cut' deeper than just the
first-run experience (e.g. handler menus). Basically, we'd need a much
more pluggable IDE to have the same ability we do with our current
approach; and, furthermore, that then still leaves us with the problem
of integrating those changes into the releases new users actually get
generally (which would muddy the 'maintenance' aspect of the stable line
anyway) rather than just in any one user testing session.
So it is a pragmatic solution to a very real problem - and one which
hadn't really occasioned much comment, until today (primarily due to the
backdrop issue I think).
So, on the whole, whilst the pedant in me has been a little
uncomfortable with it at times, that part is more than 'shouted down' by
the rest of me which can see that what we are doing is working really
quite well. Indeed, we are already getting very significant positive
results on conversion rate despite only doing it for just over a month
and with four testing sessions under our belts. (It is also being done
in concert with iterative changes to our website, emails - in fact all
parts of our processes that interact with the new and uninitiated).
Realistically, this situation isn't going to change for the foreseeable
future - and certainly not whilst it is bearing so much tasty fruit.
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode