Talk:Ideas

Uli's complaints (TODO: Better headline)

• The big rename (ZFoo): I never saw a project were this was a good idea. Of course I won't stop anyone to do this, but I won't encourage anyone either.
  • There's the initial hurdle, but in the end module developers will be happier with a beautiful and consistent API to develop with. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Semantic versions: So the only difference to right now is that we get another .0 at the end of the version number? ZNC had a grand total of two bug fix releases in its history (I think) and those were for CVEs...
  • Release early, release often. I'm sure your customers would appreciate. ;) Branching and semantic versioning in a nutshell; master branch for new features, X.Y branch for bug fixes (periodically merged to master). Bugfix releases tagged from X.Y branch, master forms the next X.Y.0 release (and eventually the next X.0). J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Binary compatibility: Just not possible. Basically every release would be a major release. Feel free to convince me otherwise, but "binary compatible" and "C++" mostly means "don't change anything".
  • My suggestion is to keep it simple and provide binary compatibility only for bugfix releases. New feature development happens in master, not in the X.Y branch where bugfix releases come from. Even for master, my suggestion would be to keep old deprecated methods and types around instead of breaking source compatibility. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Message type: Since we don't promise API stability anyway, this can happen outside of ZNCv2 (aka "can be done right now, too")
  • I'd like to kindly ask you to reconsider. ZNC has such a nice bunch of official and unofficial modules, it would be a pity to break them like that. Any module written for the 1.x series would ideally work with later 1.x releases. Write such intrusive ideas down or as TODO comments in the code. Once you have a reasonable set of changes in mind, start preparing for the next major release. Module developers know that something needs to be updated in order to support the new major version. If the changes are beneficial, module developers will surely follow. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Radically reduce the amount of module hooks: "Radically" means "4"? Also, what's the point? Most modules will check for the type of message as first thing anyway and e.g. immediately return for queries. So this just makes modules more complicated
  • Sorry, I'm not familiar enough with the CModule API to understand which hook does what, but my first impression was - please make it simpler. :) Perhaps it would be easier to understand if the module API was structured after the categories? Furthermore, ideally the interface for ZNC app wouldn't be exposed for module developers. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Project structure: Are you saying that modules must not link against symbols from the znc binary? We already have a libznc.dll for cygwin. It contains everything but main(). There just is no sane way to split things up currently, but feel free to proof me wrong.
  • The library is the part that we would retain backwards compatibility for. On the app side you may do anything you want since that wouldn't break modules. Modules shouldn't have access to application specific code. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)
• Coding style: Hahaha. No.
  • Are you laughing at all the points or some specific of them? Regarding passing certain types always by reference or as pointers... alongside good naming, consistency is one of the most important factors for easy to memorize APIs. J-P Nurmi (talk) 17:41, 6 March 2014 (CET)

Psychon (talk) 16:37, 6 March 2014 (CET)