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.

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.
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.

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).

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.

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).

Regards,
-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/

Attachment: pgpNacOvmS5CW.pgp
Description: PGP signature

Reply via email to