A Dimecres, 18 de gener de 2012 23:53:17, Mathias Behrle va escriure: > Hi, > > as early Tryton integrators and contributors from version > 0.0.1 we collected some experiences with the API migrations from > version to version, which we want to share with you and talk about. > > We think it is a benefit for all Tryton developers to be able to > migrate their modules as soon as possible. At the same time it should be > a huge benefit for the framework itself to ease migration as much as > possible resulting in > > a) more time left for other contributions and > b) increased attractiveness of the framework due to lower maintenance > costs.
I've just read the whole thread and I think it touches some very important and interesting points: a) Whether any number of API changes should be accepted per release This is probably the most controversial one. I think there's a point in it, not only for integrators but also for projects around Tryton (such as GNU Health). Being able to anticipate the amount of work API changes will bring in a new release is probably desirable for those offering support contracts that include new versions but also for planning new features. At the same time it's hard to impose those restrictions to the project. b) When those API changes are acceptable in a release cycle Even if it is subjective whether an API change is big enough, I think there's a good point in this and we can probably find some consensus. A rule that says that a large API change should not get in the code base too late in the release cycle sounds pretty reasonable to me, leaving "late" to be defined and "big" always subject to community's POV. PostgreSQL, for example, has such a rule with what they call the latest "CommitFest" in which , no big patches should be included, although the reasoning in there is usually code base stability. c) How to share code migration tools Sharing the tools one uses to migrate modules would be great I think. From simple "grep" statements to codemod [1] scripts. Although, CHANGELOG could be improved I'm not sure that's the appropriate place to share those scripts and tips. If we want to keep them in the repository, maybe we could add a new directory with a subdirectory or file per release where that information was included. That said, a wiki has the advantage that more people can easily share improvement's over the original tools. [1] https://github.com/facebook/codemod -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
