Jason van Zyl wrote: > > On Fri, 2002-04-05 at 17:50, John McNally wrote: > > Hypothetically, I want to add some functionality to intake that uses > > something in the latest cvs code of commons-foo. There is a > > commons-foo.jar in the repo that is version 1.3.1. > > > > It would seem I should be able to put a commons-foo-dev.jar into the > > repo, so that I can develop this addition to intake. > > 1) Why do you need to put the dev jar into the repo when you just built > it from CVS? There is probably a very small group of people developing > Intake and the rest of the world doesn't need that dev jar. If it's a > serious issue and you need a feature because it is a show stopper then > in the case of the commons you could push for a release like you did > with the pool code and it will likely happen. > > I mean, who is really going to benefit from the -dev JAR?
Everyone developing fulcrum would benefit, so they do not have to build from source. It is exactly the same reason for putting any other jar in the repo. You could just as easily say check out tag RELEASE_1_3_1 and build as to put a commons-foo-1.3.1.jar in the repo. Same with head. You want me to say check out HEAD and build, but I want to say download commons-foo-dev.jar. > Most of your > users don't care and if you have users that do care they aren't going to > be able to find the source for that -dev JAR very easily. When you > release a beta that requires some new feature in a product you don't > have control over you should use a date to check out that products > source and put that date on the JAR that you build so if people actually > want to look at the source for the JAR you're providing they can. When releasing, I would say it is a good idea to date an -dev jar. Until then, why? The -dev extension indicates it is the HEAD. If I wanted to freeze it to guarantee no breakage, I would put a dated version in the repo. By going with -dev, I am saying that I am taking the responsibility to fix my project, if it breaks due to changes in the HEAD. Nobody else has to worry about breaking my project, if they update the -dev jar, and I do not worry about breaking theirs if I update it. If they did not want their project to work with the HEAD they should work from a known target. > > 2) Are you going to continually release products based on unreleased > packages? Probably, it would be pretty lucky to have every dependency have a released version that worked together. So when I release, I date the dependencies, no problem there. > As mentioned above what good is a JAR that someone can't > easily find the source for if they want to patch something. Using a -dev > JAR a user will more than likely find sources in HEAD that don't match. > We have had this complaint many times. If fulcrum is using the -dev jar, I want patches applied against the HEAD, why would I want the patch applied against some old version? I then just have to get the patch to work against the HEAD anyway. > > > Having done this, > > I have to be aware that commons-foo-dev is not a static target and I may > > have to fix fulcrum when a change to commons-foo-dev.jar breaks it. > > What if you break another project you don't have access to? I just see > that -dev JAR thing as a rats nest of problems. Its only a problem for projects that are trying to keep up with the HEAD of a dependency and I don't see how dating things or putting them in cvs even helps with this. You are not keeping up then. Dating or a cvs based repo would be useful for releasing, not developing. ... > > When you get near a release you push the producers of packages you need > to do a point release, or do the date tag thing to produce a JAR that > someone can find the sources for. I agree with this. > > I suppose you could give Scarab clients a constant diet of -dev JARs but > they probably wouldn't like that I imagine. I don't understand this. > > I don't know what the perfect solution but I think that the repo isn't > the place for -dev snapshot JARs because all your developers can get the > code from CVS anyway. Developers can get the code to a lot of the jars that are in the repo, I thought the point was convenience. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
