Future development and backward compatibility

[mathieulongtin]

I appreciate that you're trying to modernize this library, but since 0.30 broke all of our existing code, I have been wondering where this is going. I appreciate that this is a pre 1.0 release, but we have a fair amount of code that depends on the old behavior that was around for 5 years or so.

We like argh because it allows us to get started quickly without any annotations, and then we can add better documentation to the arguments; argparse or click require a higher upfront amount of coding.

But with the last few updates, we have to decide "do we fork" or "do we switch everything to a more stable library"?
So I'd like to know what's your commitment to backward compatibility?
Would it make more sense to have the annotation driven system go in a new package (e.g. argh2) and not worry about backward compatibility?

[neithere]

Hi @mathieulongtin,

Thank you for your interest in the project. I appreciate your concerns.

The idea behind the latest releases was to radically clean up everything and ship a 1.0 with support both for decorators and type hints, and then drop decorators once the type hints-driven API has stabilised. I've always taken backward compatibility seriously and made sure that there's a deprecation window for every change. Breaking working code was definitely not a desired result, I'm sorry for that.

In retrospective I can say Argh has stayed for too long in v.0.x. I should have released v.0.29 as v.1.0 (LTS) and then continued the evolution under v.2.x.

Currently I'm leaning towards the following:

• release the latest state as v.1.0 — as "classic" Argh:
  • stability guaranteed — no breaking changes there anymore;
  • maintained — bugfixes + features may be backported from 2.x if that won't break anything;
  • decorators remain the primary API, perhaps annotations will gradually become equal.
• move the annotations API effort to a v.2.0 branch:
  • unstable for a while;
  • type hints become the primary API;
  • decorators are demoted to secondary API but will be maintained and I'll try to keep as much backward compatibility as possible but not if it complicates things too much;
• v.3.0 may or may not drop the decorators, I guess it will depend on the feedback. It may happen that the library will need to be split, or one of the APIs abandoned, or they will coexist happily and complement each other. Too early to say.

I would be happy to hear your opinion on this. In general, I feel a lack of feedback because there's no community around the project, so the decision making process can be flawed. Any ideas or help to overcome this is very welcome.

[mathieulongtin]

That works well. We'd be very happy with this approach.