Noel J. Bergman schrieb: > Steve Brewin wrote: > > >> Norman wrote: >> > > >>> Vincenzo Gianferrari Pini wrote: >>> > > >>>>> On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>>>> > > >>>>>> I've added this point because Noel and Vincenzo brought >>>>>> this as animportant 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. >>>>>> > > >>>> 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. >>>> > > >>> Thats right but with no new features we will loose users and not get >>> new. >>> > > We have never said NO NEW FEATURES. STOP SPREADING A FALSE MEME! > Sorry man... but is your CAPS key maybe broken... You don't need to use the CAPS key if you want me to read the text... So stop frontin! Such things make me really angry. > For JAMES v2.4, the changes should be compatible. For JAMES v3, they can be > incompatible. We all agreed on that when we met at ApacheCon. And we can > deliver both in parallel. I would expect most work from most of us to focus > on JAMES v3, and if we don't want to backport something, then it doesn't get > backported. > > >>> I think we just need to document what to change in config.xml. >>> > > Not good enough. That doesn't address that overtime, these incremental > changes could add up to a lot of require changes to migrate. > Sure it can .. but sometimes it is impossible to keep the config compatiblilty.. and have a clear UPGRADING.txt in the release will hopefully help the users. Thats was other projects also do. > >> 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. >> > > Exactly. > > --- Noel >
bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
