v2 breaking changes policy Topic is solved

Discuss the future of the AutoHotkey language
Helgef
Posts: 4072
Joined: 17 Jul 2016, 01:02
Contact:

v2 breaking changes policy

17 Nov 2019, 04:03

Hi. I have a few thoughts about a new breaking changes policy for v2, compared to v1. (Not talking about v2 alpha here, but what happens after v2.0 is released)

Introduction
In v1, generally, almost any change which can break (any documented behaviour of) existing scripts are out of the question, for ever. This has led to crap being piled upon crap, and consequently a crappy language. For v2 I would like suggest to adopt a less restrictive policy. Consider the following version system,

a.b.c.d:
  • a: Major breaking changes.
  • b: Moderate to minor breaking changes.
  • c: Non breaking changes (mainly feature additions).
  • d: Bug fixes.
This is somewhat the current way of v1, but where b only changed once (v1.0 to v1.1) in many many years, a more suitable frequency of changes to b is perhaps every one to three years. When possible, and depending of the frequency of changes to b, one can let deprecated features and their intended replacements coexist for one or some b versions, for example, consider if the addition of bufferalloc wasn't added before v2.0, then it could coexist with varsetcapacity for one b version after bufferalloc was added, before removing varsetcapacity.

Typical b-changes could be,
  • Fixing quirks such as += behaviour at the start of a line vs inside and expression.
  • Removal of #ifWinXXX after optimising and recommending #if WinXX().
  • Removal of unquoted dllcall arg types.
  • Throw on error policies vs silent failures.
  • BIF parameter ordering and behaviour.
  • ...
Less suitable b-changes would be the removal of command syntax and the big changes to the object model, these would be a-changes.

Motivation
With such a policy we can fix old mistakes, which relieves the burden of the developer to carve every change in stone, which might also increase the joy and speed of development. We might move into v2.0 faster and without feeling that the fun times of making the language better are over. A language where interesting (and necessary) changes are possible is more likely to attract developers, which can lead to a better language with more users, which again might lead to more developers and users, and so on. More frequent and smaller breaking changes are more likely to carry users over from one version to another, compared to when making all breaking changes at once.

Epilogue
Even big companies with a large teams of developers, which charges big money from their users, eventually demands their paying customers to update their software because they cannot maintain old versions. Users of free software cannot demand that every new feature of the free software is compatible with their old without any efforts on their own part. New (and old) users shouldn't pay the prize of countless quirks and limitations, only for the purpose that some ancients script are still able to run on the new versions.

Cheers :coffee:.
User avatar
nnnik
Posts: 4370
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: v2 breaking changes policy

17 Nov 2019, 05:27

I disagree.
I think that the non-breaking change policy should stay but we should be less resistant to making a new full release and just make faster full releases.
When we see that a certain aspect of the currently provided API is garbage (I could list a few things right here) we should just go on with a new major release.

I know that you are very keen on staying updated and know the ins and outs of the docs.
Most people sadly aren't like that. We therefore shouldn't make breaking changes to the language after its been fully released.
Recommends AHK Studio
just me
Posts: 6652
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: v2 breaking changes policy

18 Nov 2019, 08:22

Helgef wrote:(Not talking about v2 alpha here, but what happens after v2.0 is released)
Do you really believe in the possibility of a major release after v2? :think:
Helgef
Posts: 4072
Joined: 17 Jul 2016, 01:02
Contact:

Re: v2 breaking changes policy

18 Nov 2019, 09:21

@just me, I'm mainly talking about allowing development to make minor to moderate breaking changes at a more appropriate frequency than every time the entire language is overhauled. So that we don't have to live with countless quirks and limitations for decades, only for the sake of maintaining backward compatibility.

Anyways, the answer to your question is yes ;) .

Cheers.

Edit: hi nnnik and just me :wave:
guest3456
Posts: 2924
Joined: 09 Oct 2013, 10:31

Re: v2 breaking changes policy

18 Nov 2019, 10:51

this thread just reminded me that AHK v2 is 8 years old and still not even out of alpha stage. v2 was meant for breaking changes to fix the quirks of the language syntax to make it more consistent and easier to understand. it was NOT meant for new features. all of these new features should have been deployed in v3. i've already talked about this in my Scope Creep thread.

to say there should be an overhaul of release policy is a huge understatement

iseahound
Posts: 479
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: v2 breaking changes policy

19 Nov 2019, 00:31

Yeah feel free to go fast. No need to remove good things like command syntax however.
Helgef
Posts: 4072
Joined: 17 Jul 2016, 01:02
Contact:

Re: v2 breaking changes policy

19 Nov 2019, 01:25

Hi guest3456 and iseahound, thanks for your comments.
Speed isn't the main goal, but might be a secondary effect. V2.0 could be released earlier if we allow some decisions to be made later, and if every decision isn't taxed with the anxiety of having to live with it forever.

Cheers.
User avatar
jeeswg
Posts: 6904
Joined: 19 Dec 2016, 01:58
Location: UK

Re: v2 breaking changes policy

19 Nov 2019, 08:39

@Helgef: That sounds pretty much like the existing policy. AHK v1.1 had some breaking changes, and AHK v1.2/v2.1 could have breaking changes also.

One potentially useful change: a 1-year window, where new features could be changed before being set in stone.

@guest3456: You mention 'fix the quirks of the language syntax', but that's already been done, right? What more do you want done re. this, apart from 'in'/'contains'?

Allowing breaking changes in AHK v2 for a few years, by having it officially 'alpha' or 'beta', even when 'finished', would allow for rapid progress.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Helgef
Posts: 4072
Joined: 17 Jul 2016, 01:02
Contact:

Re: v2 breaking changes policy

19 Nov 2019, 09:07

Hi jeeswg, I already mentioned the ostensible similarities between my suggestion and the current version system, and that in practice the current one lacks the b changes. The changes to 1.b should have started years ago, I think it is too late now. We should be on 1.5 now with most of the quirks removed, and v2 should have just contained the really big changes.
One potentially useful change: a 1-year window, where new features could be changed before being set in stone.
Why should anything be set in stone? We don't have any rights to demand eternal support. What will you do if lexikos makes a breaking change past said year?

Cheers.
User avatar
jeeswg
Posts: 6904
Joined: 19 Dec 2016, 01:58
Location: UK

Re: v2 breaking changes policy

19 Nov 2019, 09:30

@Helgef: I enjoyed your post, but it's not clear what you want to change, or how it would be helpful. The problem with AHK is simply that projects in general are complex, and I don't think that formalising a release policy will be helpful here.

From my perspective, the idea that once I release something officially, it can't be changed until the next x.b.x.x release, is somewhat paralysing/stifling to development. You become reluctant to release anything officially ... am I 100% certain that the function/syntax design is perfect for all time. So, let's take AHK v1.1.31, anything there could be changed for up to a year after. It gives AHK users relative certainty/stability, and the chance to suggest amendments, and gives the dev(s) some flexibility.

You could also, for some features, warn that they might change in future. I.e. increase the flexibility offered to the dev(s).

I'm trying to suggest ideas re. breaking changes that could realistically improve the speed/quality/enjoyment of AHK releases.

[EDIT:] One other potential innovation: collected or linked to in one location: a list of former breaking changes, and a list of potential future breaking changes.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4370
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: v2 breaking changes policy

20 Nov 2019, 03:50

Just to give an example:
Do you think that a project like AHK Studio would be possible if the devs had to keep up with constantly breaking changes?
In the end I think it boils down to how fast we need breaking changes and how short we can make the timeframe during which the usage of the language remains the same.
A sane value would be taken from the list of something like: 2 years every year every half a year.

At the beginning of the time period the APIs that will get removed have to be announced and marked as deprecated in the docs. Then they are removed once the next time period starts.
Im voting for once every year since its the easiest to remember for me.
Recommends AHK Studio
Helgef
Posts: 4072
Joined: 17 Jul 2016, 01:02
Contact:

Re: v2 breaking changes policy

20 Nov 2019, 09:56

nnnik wrote:Do you think that a project like AHK Studio would be possible if the devs had to keep up with constantly breaking changes?
Regardless of who this question is directed at, I don't think anyone suggested a policy of constantly breaking changes. At least I didn't.
nnnik wrote:I disagree.
It seems that what you suggest is pretty similar to my suggestion,
helgef wrote:a more suitable frequency of changes to b is perhaps every one to three years.
nnnik wrote:Im voting for once every year
Cheers.
User avatar
nnnik
Posts: 4370
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: v2 breaking changes policy

20 Nov 2019, 15:08

Well I changed my mind. :P
Recommends AHK Studio
TAC109
Posts: 435
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: v2 breaking changes policy

20 Nov 2019, 15:55

This proposal will kill AutoHotkey. (Is @Helgef an AutoIt proponent?) We will end up with scripts which only work with certain versions of AutoHotkey 2.?! What a mess!
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
guest3456
Posts: 2924
Joined: 09 Oct 2013, 10:31

Re: v2 breaking changes policy

20 Nov 2019, 16:25

TAC109 wrote:
20 Nov 2019, 15:55
This proposal will kill AutoHotkey. (Is @Helgef an AutoIt proponent?) We will end up with scripts which only work with certain versions of AutoHotkey 2.?! What a mess!
we already have scripts that only work with certain version of AHK 1.

many scripts written for AHK 1.1 will not work with AHK 1.0

what a mess, right? its the same thing. if script writers require compatibility they could always check A_AhkVersion

TAC109
Posts: 435
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: v2 breaking changes policy

20 Nov 2019, 16:45

guest3456 wrote:
20 Nov 2019, 16:25
...
many scripts written for AHK 1.1 will not work with AHK 1.0
...
?? Forwards compatibility is what is required, not backwards compatibility (otherwise progress would be impossible).
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
nnnik
Posts: 4370
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: v2 breaking changes policy

20 Nov 2019, 17:20

A lot of scripts that work in AHK v1.0 do not work in AHK v1.1
Many scripts written in AHK 32 dont work for AHK 64 bit.
Many scripts written for AHK ANSI don't work in the unicode versions.
Scripts written for Xp sometimes dont work the same way in Win 10.

Scripts become incompatible rather frequently - it's just that they are lost just as fast.
Recommends AHK Studio
TAC109
Posts: 435
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: v2 breaking changes policy

20 Nov 2019, 17:49

V1.0 is 10 years old and the upgrade path is well documented. Many of your other cases can be classified as scripts that contain bugs.
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
iseahound
Posts: 479
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: v2 breaking changes policy

21 Nov 2019, 00:39

TAC109 wrote:
20 Nov 2019, 15:55
We will end up with scripts which only work with certain versions of AutoHotkey 2.?! What a mess!
Worst case scenario: You create a folder with the AutoHotkey.exe, and a batch file that launches the AHK script with the included executable.
TAC109
Posts: 435
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: v2 breaking changes policy

21 Nov 2019, 01:25

iseahound wrote:
21 Nov 2019, 00:39
Worst case scenario: You create a folder with the AutoHotkey.exe, and a batch file that launches the AHK script with the included executable.
Exactly! And how will this situation will help promote the use of AutoHotkey?
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 35 guests