Vincenzo Gianferrari Pini wrote: > Norman Maurer wrote: > > Vincenzo Gianferrari Pini schrieb: > > > >> Danny Angus wrote: > >> > >>> On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> I've added this point because Noel and Vincenzo brought > this as an > >>>> important point in the 2.4 roadmap discussion. > >>>> I personally don't care of config.xml compatibility: I was just > >>>> reporting what I understood was important (and feasible) > to the PMC. > >>>> > >>> Fair enough, in that case I direct my point to Noel and > Vincezo ;-) > >>> > >>> > >>> > >> We just stressed the fact that life must be kept as much > as possible > >> easy for users when upgrading to new release, otherwise > they may stay > >> behind. Regarding configurations, this goal can be achieved either > >> keeping as much as possible backward compatibility for existing > >> features, either providing (safe and thoroughly tested) conversion > >> tools. But we have to be aware that slowly adding small > configuration > >> incompatibilities can sum up to require complex conversion > tools, that > >> nobody would develop and would become a bottleneck when releasing a > >> new version. > >> > >> Open Source Communities can create better and smarter software than > >> Commercial Companies, but the latter normally care more of existing > >> "dumb" users: we should always try to reach a good > compromise ;-) . > >> > >> Vincenzo > >> > > > > Thats right but with no new features we will loose users and not get > > new.. I think we just need to document what to change in > config.xml. I > > allready add an UPGRADING.txt to the 2.3 branch. If we add some new > > feature which need things the get changed in config.xml we > just should > > document it in a UPGRADING.txt > > > The right thing to do would be to keep UPGRADING.txt up to > date *as soon > as the related code change is done*, so the documentation is > fresh and > rich. Doing it just before releasing would be less effective, because > things tend to be forgotten :-) . > > Vincenzo
Absolutely. This is why in my commercial endeavours we consider the upgrade code to be a vital part of the core product and subject to the same testing regime as all other code. It isn't an after thought, its a selling point. Something that allows our customers to easily buy into new versions, which earns us revenue, which keeps me in a job. While James doesn't have the same commercial drivers, we will lose users and kudos if we do not provide a smooth migration path between releases. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
