Re: revision to the standard that would make me happy

Travis, Thanks for the thoughtful care in this reply, I appreciate it. Travis Swicegood wrote: > Hi Greg; >> The change I'm proposing does *not* force other vendors like Zend >> Framework or Cake to do anything to their package design. On the >> contrary, the existing draft standard forces PEAR to conform to what the >> others do with BC. > > I'm sorry for being unclear. I did not mean that the change was meant > to force any particular BC model on anyone, just that - and I thought > I made this point - this request was born out of a desire to conform > to PEAR's current BC requirements and was answer the wrong question. > To me, the question is not how do we adjust the standard so that > PEAR's BC requirements can be fulfilled, it's how can we adjust code > to meet those requirements if they're added on. Yes, if the standard is already in place, this is indeed how to operate, but we are still debating whether the standard is in fact the best possible option. It seems the dueling assumptions are that the standard is the best way of doing things as-is, and my assumption that a standard should support best practices already in place - and PEAR's ability to re-factor a package into multiple sub-components is indeed a best practice that was in place for at least 3-4 years before this standard was ever conceived. > > One of the benefits of one package, one directory is that it works > well with existing tools and best practices. The current one package, > many directories structure, as can be attested to by anyone who's ever > deployed code where only portions were PEAR based, not only actively > prohibits this, but adds to the stress of re-use by causing > third-party developers to either: > > * write their own scripts for pulling in changes > * or, as is more often the case, pin their code to a specific release > and *never* upgrade > > These are side-benefits, not motivation. My apologizes for > introducing it otherwise. Thanks for clearing this up. First a side note: as you may be aware, Pyrus was specifically designed to support this use case, as installing packages and upgrading them in a bundled setting is easy and does not leave lots of cruft lying around. The suggestion I made of allowing sub-packages to be contained within their parent package naming structure still supports what you are talking about, and makes maintenance equally as easy. The only thing it could make harder is pulling the source straight from PEAR's source control, and even that may not be an issue, as most packages that are later split apart store the components in the parent package's source control, so you can still pull the whole thing in at once. To be clear: I am *only* talking about the case where an existing package is later re-factored to allow defining different stability levels and release cycles for its sub-components, without re-design of the API or changes to anything but how it is logically structured into packages. In other words, my suggestion 1) still supports the standard of having 1 directory per package 2) also extends it to allow sub-packages to reside within their parent package directory, which supports a re-factoring model that has been common - and successful - in PEAR. 3) does not in any way prevent designing the package from the beginning to be in separate packages (rather than subpackages) for its components. So we don't lose any of the rigor, and gain flexibility. Does this modified sales pitch change your mind? :) Greg