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.
> 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
