[dev] Fwd: HEAD

Eric Rostetter eric.rostetter at physics.utexas.edu
Mon Mar 24 14:31:30 PST 2003


Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting Eric Rostetter <eric.rostetter at physics.utexas.edu>:
> 
> > We could have done a Horde 3.0 release, then made the UI changes and in a
> > short time released the new Horde 4.0 with the new UI. That would have
> > been a good "release early and release often" plan.
> 
> But would the quick jump between Horde 3 and 4 have just caused us more
> trouble? With having to release applications for both branches?

I don't think so.  No more than slow releases IMHO.

> One of my goals for every major version Horde release is to make it more and
> more possible to expand that release and making it possible to build on that
> release without requiring tons of upgrades.

Sounds good, if I understand it correctly.

> With Horde 2, we *have* mostly succeeded in letting people stick with Horde
> 2.0, if they choose, and upgrade other applications mostly independantly.

Yes.  And that is a Good Thing.

> By moving to packages, I would hope to get us to a point where every app
> would have a certain set of Horde/PEAR package dependancies, and moreso,
> that upgrading, say, the Horde_Image lib would be relatively painless, so
> that Kronolith 2.1 could add image functionality that wasn't in 2.0, and
> just require a package upgrade.

Ah, that would be cool. :)

> Or some other app could add functionality
> that simply wasn't present before, and we could just release a new package
> providing that functionality - instead of requiring a whole new major Horde
> version.

Not so sure what you mean there, but it seems like that could be made to
work with a really good package manager.
 
Until this message, I had no idea what you were talking about when you said
packages/packaging.  Now I have a fairly good idea, and I like it. :)

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!


More information about the dev mailing list