Yuya Nishihara <y...@tcha.org> writes: > On Tue, 9 May 2017 11:08:03 -0700, Jun Wu wrote: >> > > Patch 12 is where I disagree. _dualmod still requires careful renaming >> > > and >> > > could cause subtle problems that does not get warned by any code checking >> > > tools. They also require extra effort in writing and reviewing related >> > > code. >> > > I'd like to go through the explicit versioning way so even the renaming >> > > churn could be avoided. >> > > >> > > [1]: >> > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097329.html >> > > >> > >> > I'm okay for the explicit versioning. I can adjust the last patch for that. >> > >> > I don't have strong preference since managing API versions would be as >> > simple as managing explicit version constants unless we have internal >> > dependency in C layer. >> >> We do have complex cases: module-level exception (mpatch.mpatchError), and >> parsers.c with complex Python objects. Think about if someone wants to catch >> mpatchError, or change the return value of lmiter_iterkeysnext in manifest.c >> for example. > > Yeah, I know. My opinion is that I won't care much about that as we don't > right now. FWIW, mpatchError isn't exported by the C module. > > That said, there seems no objection to switching to the per-module versioning, > so maybe we can go for it.
Maybe would could have a discussion of all the pros and cons? If that's overkill, then I trust Yuya to make a good call here.
signature.asc
Description: PGP signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
