AFAIK, all the Jakarta sub-projects try to ensure (but cannot guarantee) that the nightly builds remain usuable. The idea being you build and test it on your own machine before committing it to the CVS. Of course, since we are human and our tests are imperfect, the nigthly builds sometimes break. But I believe that is the exception rather than the rule, especially for products that already have a release under their belt. I believe we all hope and expect that a good number of people will be putting the nightly builds to use, so we know if what we are developing is working for everyone else.
My only point is that some products are developing against another product's nightly build, and to build product A you need the JAR from product B's nightly build. So, in addition of providing JARs alongside the formal releases, I would say it's a good idea to provide nightly JARs alongside the nightly builds, so long as it is not difficult to make this part of the automatic process. -Ted. Vincent Massol wrote: > I would say it depends on the project and the meaning you give to the > word "release". For the Cactus project, a nightly build produces exactly > the same files as a "release" and can be used with a great deal of > confidence. The only difference with a release is that a release has a > goal, i.e. we have voluntarily decided that when such and such features > are put in, then it would warrant a release. > > I like to use GUMP for 2 purposes : > * Early detection of contentions with dependent projects, > * Automated builds/integration, leading to a daily "release" (in the > agile way). Users are encouraged to use the nightly builds and not wait > for releases. > > It may be different for other projects though but I tend to like this > philosophy ... :-) > > [snip] > > -Vincent > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
