Okay, if things are versioned in such a way that the possibility of spontaneous upgrades is removed then I'm okay with it.
The release builds and the (future) nightly builds however should come bundled with everything needed to compile from scratch. -- Glen ----- Original Message ----- From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Glen Stampoultzis" <[EMAIL PROTECTED]> Sent: Thursday, April 18, 2002 5:52 PM Subject: Re: [BUILD ENHANCEMENT] No more cent jars in the CVS :-) > From: "Glen Stampoultzis" <[EMAIL PROTECTED]> > > > >>Sure Ken, but this doesn't really change my download requirements. I've > > >>still got to wait for the cents to download once I start the build. I > > would > > >>not object to having the cents included in CVS (and keeping the update > > >>feature) but I'm happy to leave that up to your good judgement. The > main > > >>thing I wanted to get rid of was the build directory and that's done now > > so > > >>I'm happy. > > > > > >Seems we have a solution everyone can live with, right? > > > > The more I think about it the more I think having the cents in CVS would > be > > a good idea. The problem arises when new versions of centipede are > released > > that break compatibility. Different people will be running potentially > > different versions of the cents. This can lead to all sorts of > > misunderstandings due to the different behaviours between versions. > > JJAR has the possibility of specifying a version. > It's currently not used, since the cents are quite new, but will be used. > > > Better to for the committers to try out a new cent then decided whether to > > make that version "standard" by checking in the new cent. All CVS users > > then get a known good version. > > The thing doesn't change, the JJAR downloaded cent can have the same version > info, and *will* have them. > > I concede that it would be nice to have been asked before the connection, > and will put it in. But this doesn't invalidate the concept. It would be > like saying: "This download system doesn't work at all because I don't get > told before". Heck, we can add it! > > Anyway, the reason why jars are not to be put in CVS is merely technical and > economical. > > Bandwidth costs. LOTS of money. Servers too. And disk space too, has to be > managed. > > Now, if every project stores in its CVS the versions they use, we have > massive duplication of jars, and much bigger disk space used. > > Also, CVS is not particularly bright as for binary files, and on some of my > machines it screwed up, and if not, it gets much more strain. > > Then Bandwidth. You have no possibility of transparent mirroring, and if you > download 100 projects, you download 100 jars of the SAME Ant. > Apache is free, and bandwith costs. > > That's why there is CPAN for Perl code, and CJAN is starting for Java. > > It's easy for me to put in CVS, and personally I like it. > > But are you still sure now that you want it? > > It will take me no time in putting it there again, but I *strongly* suggest > you to reconsider. > > CVS is for developers and developers have no problems usually in installing > the build system of a program they like. Heck, think about Linux! > > Now, I concede that the current system is not perfect, and that it needs > adjustments: > 1. ask the user to download > 2. propose manual download location of the jars and where to put them. > > Any other suggestion? > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- >
