Hi Kristis,
On Mon, Jul 12, 2010 at 09:00, Kristis Makris <[email protected]> wrote:
> On Mon, 2010-07-12 at 00:40 +0300, Yavor Nikolov wrote:
> > Which most likely should be:
> > ...
> > } elsif ( $major == 3 &&
> > ($minor == 2 || $minor == 4)) {
> > $self->{ version_type } = "up_to_3_4";
> > }
> > ...
>
> Hi Yavor, thanks for catching this. Fixed.
>
> > I'm also thinking about following: such addition of new version type
> > affects too much (i.e. even sections which don't refer to changes in
> > the particular Bugzilla version). Wouldn't it be better instead in
>
> I disagree. It's not the addition of version types that affects too
> much. It's the existence of new Bugzilla versions that affects too much.
> Bugzilla won't stop being developed and having new versions.
>
> For example, this change does not affect Bugzilla 2.14-2.22. And the
> sections that it does affect (i.e. the sections related to 3.x) are
> sections that SHOULD be reviewed. For example, re-implementing
> integration_change_bug_resolution for >= 3.1.2 by practically
> copy-pasting most of the implementation from <= 3.1.2 was a bad thing to
> do. It should be affected, it should be reviewed and it should be
> implemented with support for 3.x with as little code modifications as
> possible. I don't like the existing implementation, which is defective
> as it is: e.g. it does not connect duplicate bugs correctly like
> up_to_3_1_2 did.
>
OK - I agree sensitive code should be reviewed. My complaint was that we not
only need to review them - but we need to change them.
For example - I tried to "hack" your change about Version::create support
for bugzilla 3_4:
1. I did the modifications in integration_add_tag
2. I added "sub is_version_up_to_3_4" and the relevant change in "sub
set_version_type"
* But this was not enough - since some other things stopped working until
modified to accommodate the "up_to_3_4" addition.
I.e. - I wanted to make the smallest possible change in order to get support
for Bugzilla 3.4 in integration_add_tag. But in addition we had to also
change:
integration_change_bug_resolution
integration_get_bugs
init_specific
And none of these methods refers to something in Bugzilla which has changed
in v3.6 vs v3.4.
>
> > version-specific checks to just use something like
> > is_version_{less_than|equal|greater_than|..._or_equal,etc}( major,
> > minor, patch ).
>
> Perhaps. Perhaps not. So far my experience in implementing and
> supporting Bugzilla versions
>
> 2.14
> 2.16
> 2.18
> 2.20
> 2.22
> 2.24
> 3.0
> 3.1.2
> 3.2
> 3.4
> 3.6
>
> has been that most version changes contain minor extensions to the
> previous version. up_to_* currently means less_than_or_equal since the
> previous version. It seems to fit this model.
>
Well:
- If with each new Bugzilla releases most of the version-sensitive things
change: then current approach is fine (we'll need to change these sections
anyway).
- If only a few things change: then makes sense to touch only these few
places which are affected by that change (but not the others even though
they have been changed in some previous releases).
Currently in order to declare that some section applies for particular range
of versions: we have some long expressions checking each of them.
Calls to is_version_latest are also triggering some excessive changes since
that's influenced by each new Bugzilla release which is gets supported by
scmbug.
I should admit things are not so complex as of today - the versions
supported are not so many and the number of sensitive sections of code are
not so many. But they're growing.
Regards,
Yavor
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
