On Tue, Mar 25, 2003 at 04:40:41AM -0800, Paul Johnson wrote: > On Mon, Mar 24, 2003 at 11:26:38AM -0600, Jamin Collins wrote: > > No it's not. Version number indicate a progression of an > > application, they have no indication of "major differences between > > two releases". > > If version numbers don't describe precisely that, what does?
Usually the history or changelog, or wherever else the developer chooses to describe their changes. A version number can give an /impression/ of change, but not convey an accurate indication of the degree, or impact of these changes. This is due to the fact that everyone uses and views version numbers differently (even if only slightly so). > > Just because a package moves from 1.x to 2.x or 3.x gives no > > indication of any major changes. They are just version numbers. > > Actually, when the major number changes, that's generally an > indication that something big has changed. Not always, version number changes are at the discretion of those developing the application, and vary greatly between applications. > The Debian packaging system only understands progress and not > necissarily the ramifications of such. This could very easily be > fixed and allow for multiple versions of the same package in a > particular tree if the packaging tools would ask the user which > version they meant, and whichever version the packager recommends > using could be the default option. All this would take is adding a > single, optional flag for "default version." I'm not convinced that this alone would be enough. It may work well, provided there are only 2 versions of the package, but what happens when/if a third is needed for some reason? -- Jamin W. Collins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
