[ic] Anybody using 4.7?
Wed, 25 Apr 2001 23:00:04 +0000
Dan B wrote:
> At 02:37 PM 4/24/2001 -0400, you wrote:
> >Quoting Dan B (firstname.lastname@example.org):
> > > Yes, but I wasn't talking about catalog<-->ic compatibility. I was talking
> > > about the foundation catalog itself. My hypothesis was that foundation
> > > itself will have improvements that one might like to take advantage of
> > > between now and 4.7 release.
> > >
> > > For example: I started building my catalog in 4.5 somewhere. As part of
> > > building my catalog, I made a lot of customizations to the catalog
> > > files. When 4.6 was released, it had an updated catalog (with new
> > features
> > > such as multiple ship-to's, bugfixes, etc.) that I wanted to take
> > advantage
> > > of. However, I didn't want to re-write all the html customizations that I
> > > had done. That's where a method of forward-porting your own
> > > "customizations" becomes valuable. (Or, back-porting changes to the
> > > template: same effect).
> >Think about this. How would you have us do this? I can't see a way, and
> >if I can't it probably ain't going to happen.
> >I don't know of any program that, other than providing components as we
> >do with things like the templates/components/* stuff, which can do that.
> >If you customized those, you are probably going to have to repeat the
> >process to integrate any new features.
> >Our main changes are usually to the order features, and the method there
> >is to standardize on the same fields as we have.
> >In the payment area, one thing I am looking at is:
> > [charge-param send_form=1]
> >which would provide a standard form for each payment type based
> >on payment processor (more are requiring ccv2, for example). For the
> >dummy "PO" payment processor, you would get a form asking for po_number
> >instead of mv_credit_card_number; for online checks you would get the
> >bank routing fields, etc.
> (this looks really cool, and would really shorten checkout.html by a chunk
> of kilobytes)
> > >
> > > But yes, it is amazing how well compatibility is maintained between ic
> > > versions.
> > >
> >That is most of what we can hope for. I know of plenty of applications
> >that can
> >claim backward compatibility to some degree, but I have seen very few
> >claims of
> >forward compatibility. 8-)
> Thanks for your input, Mike. For some specific situations it *is* easy to
> "forward-port" catalog changes between minor versions. The scenario I was
> talking about was a novice user making minor (often aesthetic) changes to
> the foundation templates during the development cycle (4.7.x). Then, when
> the final foundation catalog comes out (4.8.0) one could do a "directory
> diff" (Alan Cox style) of one's existing catalog (modified from
> 'foundation' at some point in time during 4.7.x), and apply it to a new
> 4.8.x template catalog. Merge a few conflicts, and boom, you have a
> catalog with the new features/bugfixes of the final "foundation" catalog,
> without having to make all of your "minor aestheic" changes over again.
> The alternative is to backport changes to the catalog during development
> cycle, build your own catalog from scratch, or any other plethera of
> alternatives. But the above is what I did during 4.5.x development cycle
> to take advantage of the new multiple ship-to's code. But it wouldn't work
> with any valuable, substantial changes (like what we did at
> diabeticsupplies.com -- sorry, last plug ever, I promise).
> Dan Browning, Cyclone Computer Systems, email@example.com
That sounds like me - a novice making minor changes who doesn't want to
have to do it all over again when the final cat comes out. Perhaps you
could explain how to do a "directory diff" and how to develop in order
to avoid too many conflicts (-:D
Surely it would be possible, though, in some future version, to keep the
aesthetic bits seperate to anything that might be changed during the