What happened to LC version numbers?

[Mark Waddingham]

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 
there of.

> 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 - 
i.e. 8.1.x.

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 
future).

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 
users.

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 
accelerate.

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.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps