"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 12/07/2005 10:21:24 AM:
> >> > >> 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. > > I think that we're all in agreement to dump the snapshots. And I'm > not arguing against using datestamped releases of things if they come > from the source project - I find that *vastly* preferable to > SNAPSHOTS as long as the source of that dated thingy is recorded > somewhere. > > What I'm arguing against is the Geronimo project creating de facto > releases of other projects code for a bunch of reasons, including > that we'd never tolerated it being done by others. > > > > 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. > > > > Right. Agreed. No SNAPSHOTS. > > But for what I was arguing, take it a step further - that the user is > using a gernonimo-kernel jar produces by some *other* project, with > code that's not even in our SVN. Forget the date time - you could > search forever and *never* find the code that could produce the > stacktrace :) > > That's what we could potentially be doing to other projects if we > release their stuff with patches, for example. It seems that there is no practical way of removing all SNAPSHOTs (without having our own specially built "temporary" versions). For example, I sent a mail to the cglib dev list asking them to post their latest version to the maven repo and I haven't got a response in approx 2 weeks. Maybe they are busy or maybe they are on holidays. My point is that I don't think it is always going to be possible to get a project (that isn't one of the projects we are tight with) to build a special version for us when we want it. It appears we have already been building defacto releases of external libraries, e.g. the cglib library in our repo: http://cvs.apache.org/repository/cglib/jars/ Maybe a compromise is to properly document in the release notes any special versions of code we have with the following information: * Have a disclaimer stating that a special version of the library is being used temporarily and we plan on moving to the a formal release of the library as soon as possible. Maybe mention there could be a 'chance' of compatibility issues when we move to the formal version? * A description of why a special version of a library is needed and what the library is used by * The version of the code that was patched * A link/reference to the bug/issue tracking records for the problem with the library and the patch(s) that were submitted to the external project. Users would appreciate the openness and can then make their own decision on whether they are willing to run their systems on the software. They aren't given that information at the moment. If users want to report a problem with a library to an external library project, they are going to be asked what version they are using and they should see from our documentation (or by the name of the JAR in the repository) that it is a special version. > > > 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? > > Yes! Get rid of all snapshots in anything we distribute as a release > of any sort. Are you suggesting in the M4 release? > > > > > > >> > >> 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". > > Well, that's true - but we're not facing that kind of emergency > situation here. And if dependency X takes a year, and this is a > major dependency of ours, I'd vote to just get a copy of the source > and keep going with that.... :) > > I hope we never face this. > > geir > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > John 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.
