v2 breaking changes policy Topic is solved

Discuss the future of the AutoHotkey language
Helgef
Posts: 4044
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: 4364
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: 435
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 programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
Helgef
Posts: 4044
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: 2559
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.30.03 x64 Unicode | [WIN] 10 Pro (Version 1909) x64 | [GitHub] Profile
Donations are appreciated if I could help you

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: arcticir, robinson and 15 guests