On 01/21/2012 04:24 PM, Albert Cervera i Areny wrote:
> 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.
There is such a thing as refactoring-to-death. There is also such a
thing as backward-compatibility. Cédric is on a roll, doing all kinds of
really cool stuff in the backend, and improving the front-end no less.
Maintaining backward compatibility and adding deprecation warnings for
at least one release cycle will slow-down things, but will at least
provide a better platform for modifications in the custom modules. And I
agree with Mathias: customization modules are a hard necessity in any
serious deployment.
> 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.
I for one agree that more information and descriptive examples is better
than just changelog messages. Those are very terse and no: referring to
rietveld or commit-sets is no replacement for recipes and howtos. The
Transaction conversion was doable because the was a lot of people doing
similar changes, providing lots of examples of the required change
pattern. Finding those changes months or maybe years later will be that
much harder. Having a wiki page with upgrade/migration notes will be a
great boon.
Typically I suspect and expect that real-world deployments will not
upgrade to the latest and greatest whenever it comes available, just
because it's available. They will want to upgrade when not upgrading
becomes too painful. As long as the running version works ok, why change?
I make most of my money upgrading old Plone installations. And I can
tell you; unit-tests are very great, but clear and concise upgrade notes
are golden.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/[email protected]/+31.85.877.99.97
________________________________________________________________
--
[email protected] mailing list
