* Betr.: " Re: [tryton-dev] About API-Migration" (Thu, 19 Jan 2012 01:13:14 +0100):
> As I think there is no need for such limitation (even if I think we have
> never made and will never do big changes close to release date).
>
> Almost every API changes that require the code to be adapted, are done
> in such way that the code will fail to run if not changed.
> From my experience, I do the update of the official module by looking at
> failure.
I can not imagine, that you are waiting always for failures on unittests, when
you are expecting, that several modules have to be adapted for specific
chnages. It is much more time consuming to only run for failures than to fix
the code in advance.
> So here is how we work at B2CK with our custom modules that we maintain
> internally. We have unittest for each one that try to almost cover all
> the code and we run it frequently with trunk. When it fails we adapt it
> according to the last changes that have been pushed.
Trunk is clearly too unstable to be used for customer developments. Even
release 2.2 is just now getting rid of bugs and finally ready to be used for
customers. We don't think it is possible to develop on trunk for customers.
BTW AFAIR a lot of modules you propose on codereview are primarily not on trunk.
> There is also an other way to work which is to run the unittest when you
> start to work on upgrading the server, but it could be more painful
> because the changes are less fresh in your mind or in the mind of the
> community.
> But in any cases, you *must* have unittest for every modules because
> this is the only way to garantee that the behavior of the module will
> stay the same after the migration.
Or you have to adapt the unittest, yes;) Agreed.
> Also I would like to remember that series are supported for 2.5 years
> this give an average of 1.25 year to migrate and it is not required to
> migrate through each series. (I did a migration from 1.4 directly to
> 2.2).
I read it and I congratulate. I for my part had to throw some test databases
from 1.8, because they didn't migrate. I think it can work for simple setups.
The more customized and sophisticated the setup, the more problems with
migration. And there *has* to be done a lot of customization on the official
modules. It is in the nature of genericity, that they often can not meet the
specific requirements of a specific company.
> In conclusion, I don't think it is good for Tryton to prevent new
> features or improvements to come just because there is too much changes
> in the coming release. If we behave like that we will slow down a lot
> the progress of Tryton. Moreover, if the inovation is not done in
> Tryton, it will be done somewhere else and the project will lost appeal.
I am contrarily convinced, that the project will gain appeal, if it finds a way
to provide a predictable and well measured way to address the main target which
are the integrators (at least from what I am seeing until now).
We don't talk about *preventing* features, but about evaluating the amount of
effort *and* usefulness of a feature per release.
I would like to turn your mind to another important point:
We are dedicating a certain amount of our internal working time to upstream,
but our ressources to do unpaid work are limited. The more we are consumed by
migration and fixing tasks, the less we are able to participate in codereviews,
blue prints, disucussions, blue prints, release tasks, etc.. All of those latter
activities are contributions directly raising the *quality* of the framework.
We currently feel an unbalance looking at the efforts, we have to do to remain
up-to-date and the efforts, we can do to support the framework in the
conceptual phase. We like to emphasize on the importance of the conceptual
phase, because a good design will reduce the later efforts to be done for
fixing (i.e. migration).
You seem to want to push the trade-off between development speed and quality in
favor of development speed. We on the other side chose Tryton for its quality
and would like to stick to it. The goal of this thread is to discuss this
trade-off and make it planable.
> About the wiki page for migration, I thought CHANGELOG was enough as
> memorandum but we could improve it (comments in the codereview). But
> any way, I don't think the wiki is the good place for such document as
> it must be maintain as close as possible to the code just like the
> documentation (don't repeat past mistakes).
It seems you misunderstood or misread the wiki page.
It is not just another CHANGELOG, but
1) a collection of all, but jest the necessary steps to do a migration
2) a collection of recipes how to do the migration
I don't see how you want to put this near to the code.
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
