Modifying code and testing it against new Bugtracker version are different things: - I agree places where we have branching with version specific checks are considered more brittle. - But this doesn't mean we shouldn't test paths on which we haven't made changes in scmbug. (We should test all Bugzilla calls since they may have changed in Bugzilla /or whatever other bugtracker is used/). - I don't see how exactly does the need to change more code in different places does contribute to better testing of new bugtracker version nor how does it help to add support for new change. In both cases we should make sure things work fine. - e.g. the example with new version of add_comment has appeared. It's easier for me to make a mistake omitting a necessary change in some of the "long expressions" vs to just review and make the necessary changes just where needed.
---- * Some other reasons of avoiding these predicates "is_version_up_to_...()" predicates just didn't look very straightforward to me at first (they still don't). E.g. - what does it mean is_version_up_to_3_4() returns true: - does it mean all versions <= 3.4? - or it does it mean just all 3.4.x versions? - does it mean 3.2 is included in that check or not. - OK - it's not impossible to answer that question but the answer is not so obvious just from that expression - usually involves consulting set_version_type which leads to distraction. - Change of set_version_type could affect the meaning of many such expressions. * Imagine Bugzilla starts releasing new version e.g. each month. --- Anyway - I'm not so insistent to have this changes merged. The general idea was to experiment with that to see how do things look like in reality (adapting to Bugzilla 4.0 seems a good chance to make such comparison). Regards, Yavor On Sat, Mar 5, 2011 at 16:51, Kristis Makris <[email protected]> wrote: > On Sat, 2011-03-05 at 09:31 +0200, Yavor Nikolov wrote: > > - and which is more important - when a new change is introduced in > > place X - I want to avoid changing all the other places which have > > nothing to do with that change X. > > This is incorrect. The other places that appear to have nothing to do > with that change are the places where the change breaks. > > You should not avoid changing it. You should want to test if it is > necessary to change it. > > For example, a patch is supplied that adds support for some new version > of Bugzilla for add_comment, and the patch ignores tagging. Tagging is > not tested at all. The VDD is not tested at all. It appears that more > work is needed to change all those other places, but in fact those other > places are not tested. > > If the change involves compatibility changes, they should be handled. > This won't change. >
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
