Return-Path: Delivered-To: apmail-xml-general-archive@xml.apache.org Received: (qmail 26305 invoked by uid 500); 18 Jun 2001 13:57:38 -0000 Mailing-List: contact general-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: general@xml.apache.org Delivered-To: mailing list general@xml.apache.org Received: (qmail 25957 invoked from network); 18 Jun 2001 13:57:34 -0000 Subject: Standardized version query? To: general@xml.apache.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Joseph_Kesselman@lotus.com Date: Mon, 18 Jun 2001 09:56:35 -0400 X-MIMETrack: Serialize by Router on CAMMAIL08/CAM/M/Lotus(Release 5.0.7 |March 21, 2001) at 06/18/2001 09:56:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Apologies if folks are already pursuing something like this, or have considered and rejected it, but I figured I'd toss it out and see how quickly it sank... I've been noticing that while most of the Apache projects I've played with include a routine that can return the version number of the package -- which is wonderful -- they aren't remarkably consistant about where that routine is kept. java org.apache.xalan.processor.XSLProcessorVersion org.apache.xerces.framework.Version and so on. Might it make sense for everyone to converge upon a single standard org.apache.xerces.Version org.apache.xalan.Version ... etc., perhaps all implementing a shared abstract-version API that lives in the "commons" package? And perhaps to do something equivalent for the C++ code, if it has the same scattering of solutions? I'm not dogmatic about exactly what that API should look like, as long as it's consistant. I'd be willing to settle for a main() that printed a version string on stdout (for convenient checking from the command line) and a getVersion() which returned that string so applications could report which level they were running against. If we wanted to get fancy about it, we could make the subfields of the string individually retrievable -- which would allow applications to test exactly what they were running against and perhaps apply workarounds for specific versions. But I think that's more complication than we really need right now. --------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: general-unsubscribe@xml.apache.org For additional commands, e-mail: general-help@xml.apache.org