Hi List, I was trying to get all apycot tests run by logilab.org and cubicweb.org to turn green when I realised the following.
At http://www.cubicweb.org/project/cubicweb?tab=apycottest_resultstab one can see a table with many differents tests. Three different branches are listed: default, stable and oldstable. cubicweb default is tested with logilab-common default, cubicweb stable is tested with logilab-common stable, cubicweb oldstable is tested with logilab-common unstable. Stated like this, everything souds right, but it is not. Here is why: step 0 - cubicweb version 1.0.0 is released. It depends on logilab-common 1.0.0 and the status is: cubicweb 1.0.0 = oldstable = stable (depends on common 1.0.0) logilab-common 1.0.0 = oldstable = stable step 1 - logilab-common 1.1.0 is released and the status becomes: cubicweb 1.0.0 = oldstable = stable (depends on common 1.0.0) logilab-common 1.0.0 = oldstable logilab-common 1.1.0 = stable step 2 - cubicweb 1.1.0 is released that depends on common 1.1.0 and the status becomes: cubicweb 1.0.0 = oldstable (depends on common 1.0.0) cubicweb 1.1.0 = stable (depends on common 1.1.0) logilab-common 1.0.0 = oldstable logilab-common 1.1.0 = stable step 3 - logilab-common 1.2.0 is released and the status becomes: cubicweb 1.0.0 = oldstable (depends on common 1.0.0) cubicweb 1.1.0 = stable (depends on common 1.1.0) logilab-common 1.0.0 logilab-common 1.1.0 = oldstable logilab-common 1.2.0 = stable As you can see, at step 3, cubicweb 1.0.0 is oldstable, but depends on logilab-common 1.0.0 that is "very-old-stable" and trying to test it with logilab-common oldstable (1.1.0) makes no sense since it is not expected to work (cubicweb 1.0.0 was released before logilab-common 1.1.0 that introduced API changes). It may be the case that it works, but if we know that there is no chance that it works, we should be able to prevent the tests form being run and turn red in the dashboard. Of course this is not limited to the branch named oldstable, at step 3, cubicweb stable depends on common 1.1.0 when common stable is 1.2.0. If you ask about backward compatibility, I'll answer that it is not necessarily maintained for ever. With cubicweb, backward compatibility is maintained for two versions after an API change. Replace logilab-common 1.2.0 with logilab-common 1.4.0 in the example above and the backward compatibility policy can not save cubicweb 1.0.0 from breaking with the most recent release of the library it is using. The conclusion is that the test configuration can not rely on branch names. It has to use version numbers to be correct. This information would be a burden to maintain by hand, but it is currently provided in the __pkginfo__ and should be extracted from there. In the case described above, after the release of logilab-common 1.1.0, the __pkginfo__ for cubicweb 1.0.0 would have to be updated to say "this version does not work with common 1.1.0". BTW, __pkginfo__ served us well for years, but now that a new format is spreading and about to become a standard (cf http://www.python.org/dev/peps/pep-0345/), we should probably get our __pkginfo__ to read its data from a PKG-INFO file. And for version comparison, maybe the logilab tools would benefit from using http://www.python.org/dev/peps/pep-0386/ Unless someone on this list has a good reason for us not to move forward with this, we will implement http://www.logilab.org/ticket/20882 http://www.logilab.org/ticket/20883 http://www.logilab.org/ticket/20884 Cheers, -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances _______________________________________________ Python-Projects mailing list Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
