"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 12/07/2005 08:46:53 AM:
> > On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote: > > > Geir Magnusson Jr. wrote, On 7/11/2005 5:39 AM: > > > > > >> > >> On Jul 11, 2005, at 7:46 AM, Jacek Laskowski wrote: > >> > >> > >>> [EMAIL PROTECTED] wrote: > >>> > >>> > >>> > >>>> Can't we resolve the SNAPSHOTs issue by modifying the branch > >>>> before releasing and at least using dated jar files if we can't > >>>> move to a formal release of a dependency? > >>>> > >>>> > >>> > >>> How could we use the dated jar files? Do they have to be > >>> released by respective projects or can we do it ourselves? > >>> > >> > >> > >> They have to be released by respective projects. > >> > > > > Not technically true. We can generate our own snapshots, e.g. > > > > outside-project-GERONIMO-200507111432.jar > > > > The problem is that there are a *ton* of projects that we use. > > I think this is a bad idea. We would be in effect publishing/ > distributing software that > > a) isn't ours in that we have no real clue over the provenance and > > b) isn't something we'd want to see done to us. > > I mean, would you like to see geronimo-kernel- > jboss-200507111423.jar? Or have to deal with questions about > stacktraces and behavior that we just can't understand because it > comes from code that really isn't ours? Yes I would prefer that to the current situation of using SNAPSHOTs. Just say a user does send us a stack trace.. If they are using SNAPSHOTs, how do we know what day/time their SNAPSHOT was taken? How do we go about reproducing their problem considering that if we try to rebuild Geronimo to match their environment we will most likely end up with something different, since some of the SNAPSHOT dependencies have been updated since. Something I haven't considered is what if the SNAPSHOTs we are depending upon are also depending upon SNAPSHOTs. Looks like we need to dump the whole tree of dependencies and identify where the SNAPSHOTs are? > > Now, I realize that we are really close to some projects (like have > 100% committer overlap) so you might say that we do have a clue, but > I wouldn't want to set the practice, if we are so close then why not > just do it 'there', etc > > When we create software for distribution, which is exactly what we'd > be doing here, we are making a statement that this software conforms > to the ASF process for IP provenance, oversight, etc... How are we going to deal with the situation where just before a release or after a release a serious bug is found where changes are needed to be made to a dependency. Users are not going to accept "Oh, we can't ship a new release until dependency x fixes the problem and ships a formal release, which may be a week or it may be a year". Here is a (hopefully not too stupid) analogy.. If you buy a car and the brakes fail, would you be happy if the car company said you had the choice of: a) to wait until the revised brake components come off one of their supplier's production lines and they don't know when that is? The car company cannot expect the production line to tool up immediately just for them because they are already committed to manufacturing other models of components for other manufacturers (waiting for a formal version of a dependency). b) use some brake components they found lying around at the factory. They aren't sure when they were made and what revisions may have been made to their design since and what problems they may have had in their design (SNAPSHOTs) c) A technician from the car company takes your brakes and makes some small modifications to rectify the problem and puts the car through the standard brake tests and has documented information on what they did (versioned SNAPSHOTs) I think this is a serious issue and we need to discuss how this is going to be addressed going forward. Thanks, John > > Just my 0.02 :) > > geir > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
