v2 breaking changes policy Topic is solved

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

Re: v2 breaking changes policy

21 Nov 2019, 02:29

TAC109 wrote:
20 Nov 2019, 15:55
This proposal will kill AutoHotkey.
Can you explain why? Can you explain how the (in effect) never breaking policy of ahk v1.1 has made autohotkey a better language? Compare to if we every one to three years would have made minor to moderate breaking changes to fix quirks, limitations and other undesirable behaviour, syntax and features.
Forwards compatibility is what is required, not backwards compatibility (otherwise progress would be impossible).
I'm not sure what you mean by this, AHK v1.1 is littered with behaviour, deprecated syntax and features due to backward compatibility, behaviour, features and syntax which regularly confuses old and new users, causes headaches, and countless ask for help topics and false bug reports. And ahk v1.1 is not at all forward compatible with v2.

Anyways, the good news is that you are not required to update, you can continue to use 1.1.31.01 for free. But don't expect anyone to add features and fix bugs for you. And certainly don't expect it to be free without you even paying back some of your time to maintain your own scripts. The idea that one has the right to expect this is almost rude.

Also note that this is not a debate on whether breaking changes should be allowed or not, it is about a policy, not a law. lexikos can make any changes he likes at any time, no one have any rights or guarantees. A policy which better balances community effort (to adapt to useful changes) and developer restrictions (to make useful changes) will make a better language, that is not a debate, it is law.

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

Re: v2 breaking changes policy

21 Nov 2019, 04:11

It will make it possible to modifz bad parts of the language. How wouldn't that help with the usage of AHK?
Recommends AHK Studio
TAC109
Posts: 595
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: v2 breaking changes policy

21 Nov 2019, 04:33

@Helgef
I agree with what you say about AutoHotkey 1.1 it does have odd quirks but this is due to its birth from AutoIt and later development. Recently certain features have been flagged as 'depreciated' in 1.1 simply because they don’t translate easily to version 2. They still work fine in version 1.1 and will continue to do so in subsequent version 1.1 updates, so there is a certain dishonesty in the documentation.

Version 2 was going to be the fix for the 1.1 quirks but seems to be developing into an out of control monster. Every new version breaks compatibility with previous versions and goes deeper and deeper into the OOP paradigm - fine for experienced programmers brought up with OOP but not so good for others. What you’re proposing seems to be to continue the alpha-type breaking-changes development into the released product.

It is really depressing to think that the developers appear to have no vision as to where the continuing development of version 2 is heading, so that they need to have an 'out' so that they can remove features that they once thought were a good idea.

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
Helgef
Posts: 4464
Joined: 17 Jul 2016, 01:02
Contact:

Re: v2 breaking changes policy

21 Nov 2019, 07:48

TAC109 wrote:
21 Nov 2019, 04:33
What you’re proposing seems to be to continue the alpha-type breaking-changes development into the released product.
Not at all.
It is really depressing to think that the developers appear to have no vision as to where the continuing development of version 2 is heading, so that they need to have an 'out' so that they can remove features that they once thought were a good idea.
It is, luckily, this is not the case. Inevitably, no matter how much time is spent on perfecting v2, eventually, after its release, things will turn out to not work out as once expected, some old ideas will be incompatible with new ideas and so on. That has nothing to do with lack of vision, that is how all (software) development goes.

Cheers.
Spoiler
User avatar
jNizM
Posts: 2665
Joined: 30 Sep 2013, 01:33
GitHub: jNizM
Contact:

Re: v2 breaking changes policy

29 Nov 2019, 07:38

Personally I like this kind of versioning for AHK:
Helgef wrote:a.b.c.d:
  • a: Major breaking changes.
  • b: Moderate to minor breaking changes.
  • c: Non breaking changes (mainly feature additions).
  • d: Bug fixes.


For reference only:
Development Cycle of Python

The responsibilities of a core developer shift based on what kind of branch of Python a developer is working on and what stage the branch is in.

To clarify terminology, Python uses a major.minor.micro nomenclature for production-ready releases. So for Python 3.1.2 final, that is a major version of 3, a minor version of 1, and a micro version of 2.

  • new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;
  • new minor versions are feature releases; they get released roughly every 18 months, from the current in-development branch;
  • new micro versions are bugfix releases; they get released roughly every 6 months, although they can come more often if necessary; they are prepared in maintenance branches.
We also publish non-final versions which get an additional qualifier: Alpha, Beta, release candidate. These versions are aimed at testing by advanced users, not production use.

Each release of Python is tagged in the source repo with a tag of the form vX.Y.ZTN, where X is the major version, Y is the minor version, Z is the micro version, T is the release level (a for alpha releases, b for beta, rc release candidate, and null for final releases), and N is the release serial number. Some examples of release tags: v3.7.0a1, v3.6.3, v2.7.14rc1.

(https://devguide.python.org/devcycle/)
[AHK] 1.1.32.00 x64 Unicode | [WIN] 10 Pro (Version 2004) x64 | [GitHub] Profile
Donations are appreciated if I could help you
Adventurer
Posts: 5
Joined: 18 Apr 2019, 06:24

Re: v2 breaking changes policy

14 Mar 2020, 02:11

guest3456 wrote:
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
I sadly have to agree with this. AHKv2 is more or less looking like it's never going to actually happen. Several projects that were supporting AHKv2 gave up because of the constant breaking changes. We would be in a much better place if AutoHotkey had just gotten a major stable release once every two years that implemented big chunks of these breaking changes, it's a reasonable amount of time. Instead we're 8 years into an alpha.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 5 guests