Re: RE: XML_Tree2 vs XML_Tree 2.0.0

On 30 May 2004 at 13:25, Adam Go biowski wrote: > On Sun, May 30, 2004 at 10:04:31AM +0100, Davey wrote: > > I just wanted to comment on this before I go away till tuesday. > > > > I have read the thread and will probably do the following: > > > > Release an XML_Tree2 2.0.0RC3 - there are still some bugs I need to > > catch, and rules state you need at least one RC before stable ;) > > > > Release an XML_Tree2 2.0.0 - Stable release. > > > > I am not sure what to do with XML_Tree yet, I'll re-read the thread for > > ideas on tuesday. > > IMO such a versioning policy is not a good thing. What will happen in > next few years? We will have package Foo, Foo2, Foo3 through FooX just > because it was actively developed. > > PEAR repository will turn into garbage, where we will have X-1 Foo > packages which are unmaintained (what for?) and only one FooX that will > be developed. > > I didn't see such a versioning anywhere in the web, where breaking BC > (and thus changing major) forces owner of the package to fork it. > > Do you really plan to maintain XML_Tree after XML_Tree2 is relased? Even > if so, for how long? How many releases will there be? One, maybe two > that contain only bugfixes? And then what? XML_Tree will cover with > dust. So you advocate for having just one "branch" and not really forking off separate packages / classes? Well, this topic has been extensively discussed before - and we're through with it, sorry! To explain the ideas behind it: This is the only way to ensure that several scripts using different major versions can actually coexist - on the same server, and included at the same time (if needed). This is the only way that you can still run your old app next year without braking everything although your ISP upgrades to a new major version to support the addition features. Please don't just think about one special app, or the case that you have the total freedom on your server and know for sure what will break after an update. There are often environments where life is not that easy (e.g. hosting). Stefan