Re: [fossil-users] Fossil source download naming scheme
On Wed, 25 Feb 2015, Stephan Beal wrote: On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp d...@sqlite.org wrote: So it seems like having dates on the download would be more meaningful than having a made-up version number. No? With a date, at least you know about how old the code is. What information does a made-up version number provide? How is that better than a date? FWIW, that's the approach i've taken for all but one of my own projects the past 15 years. Version numbers, _unless_ they are accompanied by a strict set of compatibility rules involving API- and/or binary compatibility, are _absolutely meaningless_. [joke] If we all were paleontologists, we could use the names of fossil animals for significant milestones of Fossil SCM http://www.fossilrecord.net/ http://www.fossilrecord.net/dateaclade/index.html http://www.fossilrecord.net/fossilrecord/download.html Sergei___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 8:03 PM, jungle Boogie jungleboog...@gmail.com wrote: For my day job, version numbers in ANY capacity are out of the equation (NOT my choice). The project in question either in trunk/head or its in some branch. It pretty much means filing bug reports are useless since we can't really identify when an issue first occurred. I'd be happy for a version number, svn rev number, or a date in my work's product. Too bad it's not my decision to change this, although I've filed a bug report to have it included. ;) So, users of your products have no way to identify what release they are using? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On 25 February 2015 at 11:03, Ron W ronw.m...@gmail.com wrote: On Tue, Feb 24, 2015 at 8:03 PM, jungle Boogie jungleboog...@gmail.com wrote: For my day job, version numbers in ANY capacity are out of the equation (NOT my choice). The project in question either in trunk/head or its in some branch. It pretty much means filing bug reports are useless since we can't really identify when an issue first occurred. I'd be happy for a version number, svn rev number, or a date in my work's product. Too bad it's not my decision to change this, although I've filed a bug report to have it included. ;) So, users of your products have no way to identify what release they are using? Unfortunately, that's correct. I have no idea why we don't include some version or revision number in our product. The customer likely won't care but for bug reporting, it's ideal as when the bug is reviewed, QA knows what to test against. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 8:00 PM, Richard Hipp d...@sqlite.org wrote: On 2/24/15, Ron W ronw.m...@gmail.com wrote: [Managers] associate dates with deadlines, so version numbers remove a source of panic. Fair enough. I'll migrate from dates to version numbers in the next release. I was only responding to Stephan's comment about the uselessness of version numbers. Whether Fossil identifies releases via a version number or a date/time stamp doesn't matter to me or my team. On the other hand, most applications my team and I (and other coworkers) use do use version numbers. (Some even use x.y.z.n where n appears to be either a commit number (al a SVN) or build number from a master build server.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Wed, Feb 25, 2015 at 11:13:22PM +0300, Sergei Gavrikov wrote: If we all were paleontologists, we could use the names of fossil animals for significant milestones of Fossil SCM What fossil are of interested other than Trilobites?! Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
Archeopteryx (proto-bird) On Wed, Feb 25, 2015 at 1:12 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Feb 25, 2015 at 11:13:22PM +0300, Sergei Gavrikov wrote: If we all were paleontologists, we could use the names of fossil animals for significant milestones of Fossil SCM What fossil are of interested other than Trilobites?! Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/24/2015 3:21 PM, Ron W wrote: Took a quick look at Fossil commits tagged release, I see tags like version-1.31, version-1.30, etc. I also see references to SQLite versions in the form x.y.z as opposed to a date string. Seems like x.y or x.y.z version numbers are already entrenched in Fossil. So just grab the file at this URL: https://www.fossil-scm.org/fossil/tarball/fossil-1.31.tar.gz?uuid=version-1.31 and be happy. The file will have the name you want. Or replace 1.31 with whichever tagged release you desire. The feature you want already exists. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU7PFdAAoJELtYwrrr47Y4DAgH+QGwXmn8hA1PopVf6QaLfN4f 1qrzlSHX9BfdZJq5rNudvJMcg9GM2Bv6TKrHYUvny/m8OJHpToEV74NzvriRQwES C3YWesphl54ZrKXdLw/GqUspKRXF18feg2eTVkh2smrYgExNpXi0rJLHjdw9AjQh DiKHWq9qG+OZEtx54ALHZrYnQPtUS+rpWVTczQ7oWdp1wUtXQAPoybL3YDdMvdd4 uf1J/aWWiK1Fm7u8V86TWSkWAZHSqq0jzYVsfkdOzk87NUtnrgAMGFY6LO3JNbN9 8OlFW7Nftc2T8k0BVywudm388hZcWOL/vG897hJPot4Gu2dbQ+zlwnl48UPM6Lk= =daCa -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
Am Tue, 24 Feb 2015 12:04:06 -0500 schrieb Ron W ronw.m...@gmail.com: But, in any case, Mr robotanarchy seems to be requesting that the official release tar file be created with, for example: fossil tarball version-1.31 fossil-src-1_31.tar.gz --name fossil-src-1_31 to make it easier to identify the released versions. I'd replace the underscore with a dot, so it becomes fossil-1.31.tar.gz ..but other than that, that's my point. Can you guys do that? Thanks. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
Hi Joe, On 24 February 2015 at 12:38, Joe Prostko joe.pros...@gmail.com wrote: I think this is mostly handy for packagers, where it's easier to write a packaging script knowing the downloaded file will be somepieceofsoftware-1.2.3.tar.gz, which then extracts out to somepieceofsoftware-1.2.3. It is mostly a matter of following convention though used with most other software, as I admit I personally don't care at all what the filename is and what it extracts to, as long as the method is consistent (or mostly consistent) from release to release. That said, if the version number isn't important, why didn't you call the latest release Fossil 20150223162734 instead of Fossil 1.31? I think it's useful to keep the naming scheme consistent in as many places as possible, when possible. To be honest, I don't think most people care about the date of a software release, but they are interested in having the latest stable version, whatever that is. As you said, the versions for Fossil are snapshots, but a lot of people correlate something like Fossil 1.31 as being the latest stable, regardless of it actually meaning that or not. How have you been updating packages in the past? All releases are like this: 20150223162734 20150119112900 20140612172556 20140127173344 2013094349 -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 4:21 PM, Ron W ronw.m...@gmail.com wrote: Took a quick look at Fossil commits tagged release, I see tags like version-1.31, version-1.30, etc. I also see references to SQLite versions in the form x.y.z as opposed to a date string. BTW, would be useful to have an entry in the search type pull-down for tags (there were a lot of occurrences of release in the comments). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
Hi Ron, On 24 February 2015 at 13:24, Ron W ronw.m...@gmail.com wrote: BTW, would be useful to have an entry in the search type pull-down for tags (there were a lot of occurrences of release in the comments). Although not exposed as a menu option there is this link: http://fossil-scm.org/index.html/taglist Yes, it would be nice to have a search filter for tags since you can do that in the URL. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 3:59 PM, jungle Boogie jungleboog...@gmail.com wrote: How have you been updating packages in the past? All releases are like this: 20150223162734 20150119112900 20140612172556 20140127173344 2013094349 Took a quick look at Fossil commits tagged release, I see tags like version-1.31, version-1.30, etc. I also see references to SQLite versions in the form x.y.z as opposed to a date string. Seems like x.y or x.y.z version numbers are already entrenched in Fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 3:11 PM, Richard Hipp d...@sqlite.org wrote: On 2/24/15, robotanarchy robotanar...@bingo-ev.de wrote: I'd replace the underscore with a dot, so it becomes fossil-1.31.tar.gz ..but other than that, that's my point. Can you guys do that? We can call things whatever we want. It's just a name. The question is Why?. Fossil's trunk is usually stable enough for everyday use. Indeed, the self-hosting server for Fossil, as well as the repos for SQLite and Tcl/Tk are all usually running from the latest trunk, or something close to that. The releases are not somehow more stable. They are merely snapshots that provide convenient download points for users. No argument from me there. So it seems like having dates on the download would be more meaningful than having a made-up version number. No? With a date, at least you know about how old the code is. What information does a made-up version number provide? How is that better than a date? I think this is mostly handy for packagers, where it's easier to write a packaging script knowing the downloaded file will be somepieceofsoftware-1.2.3.tar.gz, which then extracts out to somepieceofsoftware-1.2.3. It is mostly a matter of following convention though used with most other software, as I admit I personally don't care at all what the filename is and what it extracts to, as long as the method is consistent (or mostly consistent) from release to release. That said, if the version number isn't important, why didn't you call the latest release Fossil 20150223162734 instead of Fossil 1.31? I think it's useful to keep the naming scheme consistent in as many places as possible, when possible. To be honest, I don't think most people care about the date of a software release, but they are interested in having the latest stable version, whatever that is. As you said, the versions for Fossil are snapshots, but a lot of people correlate something like Fossil 1.31 as being the latest stable, regardless of it actually meaning that or not. - joe ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On 2/24/15, robotanarchy robotanar...@bingo-ev.de wrote: Hello Fossil developers, I was building the fossil binary yesterday and I've noticed that the names of the tarballs aren't very userfriendly. As I see it, there are two tarballs that one could use, one is from the downloads page [1] and one is by using some strange SHA1 hash of the release, as in the Arch Linux package [3]. When downloading file [1], you'll get an archive that has a different file name than the included folder. The folder has different numbers at the end: fossil-src-201502231627 That's the date: 2015-02-23 16:27 Providing a date on the filename seems (to me) a lot more useful than a random SHA1 hash. My point is that all filenames don't contain the actual version name, which would be the really helpful information here. Could you please change the names to the following format (or at least provide these additionally)? Name of the tarball: fossil-$version.tar.gz Name of folder in tarball: fossil-$version Also thanks for making Fossil, I use it a lot! Kind regards, robotanarchy [1]:https://www.fossil-scm.org/download/fossil-src-20150223162734.tar.gz [2]:https://www.fossil-scm.org/download.html [3]:https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/fossil ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
Am Tue, 24 Feb 2015 15:33:42 +0100 schrieb Stephan Beal sgb...@googlemail.com: On Tue, Feb 24, 2015 at 3:30 PM, Richard Hipp d...@sqlite.org wrote: Providing a date on the filename seems (to me) a lot more useful than a random SHA1 hash. +1, if only because they retain their release order when sorted lexically. Maybe I didn't write that clear enough - with $version I meant the actual version number, not a hash. For the current version 1.31 (as listed in the downloads page), this would be: fossil-1.31.tar.gz That's what I'd like to see, not the hash or date. Regards, robotanarchy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
Just to throw my thought on this into the discussion. I'd really appreciate having a static url to get the latest stable/testing sources from. So to be able to download from https://www.fossil-scm.org/download/fossil-src-stable.tar.gz the latest stable sources. Maybe that even makes it possible to let maintainers use the source to build packages for the distributions with less effort. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On 2/24/15, Oliver Friedrich redtalonof+mailingl...@gmail.com wrote: Just to throw my thought on this into the discussion. I'd really appreciate having a static url to get the latest stable/testing sources from. https://www.fossil-scm.org/fossil/tarball/fossil-src-stable.tar.gz?uuid=release So to be able to download from https://www.fossil-scm.org/download/fossil-src-stable.tar.gz the latest stable sources. Maybe that even makes it possible to let maintainers use the source to build packages for the distributions with less effort. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 5:01 PM, Richard Hipp d...@sqlite.org wrote: On 2/24/15, Oliver Friedrich redtalonof+mailingl...@gmail.com wrote: I'd really appreciate having a static url to get the latest stable/testing sources from. https://www.fossil-scm.org/fossil/tarball/fossil-src-stable.tar.gz?uuid=release And for testing, replace uuid=release with uuid=trunk. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 03:52:56PM +, Oliver Friedrich wrote: Just to throw my thought on this into the discussion. I'd really appreciate having a static url to get the latest stable/testing sources from. So to be able to download from https://www.fossil-scm.org/download/ fossil-src-stable.tar.gz the latest stable sources. You can use the release tag. http://fossil-scm.org/index.html/tarball/Fossil-release.tar.gz?uuid=release -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
2015-02-24 15:30 GMT+01:00 Richard Hipp d...@sqlite.org: On 2/24/15, robotanarchy robotanar...@bingo-ev.de wrote: Hello Fossil developers, I was building the fossil binary yesterday and I've noticed that the names of the tarballs aren't very userfriendly. As I see it, there are two tarballs that one could use, one is from the downloads page [1] and one is by using some strange SHA1 hash of the release, as in the Arch Linux package [3]. When downloading file [1], you'll get an archive that has a different file name than the included folder. The folder has different numbers at the end: fossil-src-201502231627 That's the date: 2015-02-23 16:27 Along the time it has changed a couple of time: until (included): 20110101030647 it was MMDDhhmm for both the tarbal and the directory inside then it became MMMDDhhmmss for both the tarbal and the directory inside and with the last one it is MMMDDhhmmss for the tarbal and MMDDhhmm for the directory inside. The last version is the less convenient for a package maintainer imho. Regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 11:27 AM, Baptiste Daroussin baptiste.darous...@gmail.com wrote: 2015-02-24 15:30 GMT+01:00 Richard Hipp d...@sqlite.org: On 2/24/15, robotanarchy robotanar...@bingo-ev.de wrote: When downloading file [1], you'll get an archive that has a different file name than the included folder. The folder has different numbers at the end: fossil-src-201502231627 That's the date: 2015-02-23 16:27 Along the time it has changed a couple of time: until (included): 20110101030647 it was MMDDhhmm for both the tarbal and the directory inside then it became MMMDDhhmmss for both the tarbal and the directory inside and with the last one it is MMMDDhhmmss for the tarbal and MMDDhhmm for the directory inside. Looking at the CLI docs for tar: Usage: fossil tarball VERSION OUTPUTFILE [--name DIRECTORYNAME] [-R|--repository REPO] Generate a compressed tarball for a specified version. If the --name option is used, its argument becomes the name of the top-level directory in the resulting tarball. If --name is omitted, the top-level directory named is derived from the project name, the check-in date and time, and the artifact ID of the check-in. It talks about generating a name for the top-level directory, but not the tar file. The implication being that the tar file name must be explicitly supplied. But, in any case, Mr robotanarchy seems to be requesting that the official release tar file be created with, for example: fossil tarball version-1.31 fossil-src-1_31.tar.gz --name fossil-src-1_31 to make it easier to identify the released versions. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 3:59 PM, jungle Boogie jungleboog...@gmail.com wrote: Hi Joe, How have you been updating packages in the past? All releases are like this: 20150223162734 20150119112900 20140612172556 20140127173344 2013094349 I just used those as they were without issue. See any of the recipe files here: http://bb.haikuports.org/haikuports/src/3acdb243c266b70a2051fa370f2e8e8b83fa4bff/dev-vcs/fossil That said, it would be cleaner to just use our $portVersionedName variable (for example, which would return fossil-1.31) in SRC_URI and SOURCE_DIR if the filename were fossil-1.31.tar.gz and the extracted directory were fossil-1.31, for instance. There would be less to change in the recipe files from version to version (only the sha256sum), although admittedly, changing three lines isn't exactly a huge ordeal. :) In any case, it totally doesn't bother me at all the way things are now, but it's different than the way most software tarballs are done. As Richard mentioned, this can all wait until 2.0, for sure. - joe ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On 2/24/15, Andy Goth andrew.m.g...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/24/2015 3:21 PM, Ron W wrote: Took a quick look at Fossil commits tagged release, I see tags like version-1.31, version-1.30, etc. I also see references to SQLite versions in the form x.y.z as opposed to a date string. Seems like x.y or x.y.z version numbers are already entrenched in Fossil. So just grab the file at this URL: https://www.fossil-scm.org/fossil/tarball/fossil-1.31.tar.gz?uuid=version-1.31 and be happy. The file will have the name you want. Or replace 1.31 with whichever tagged release you desire. The feature you want already exists. It's going to be more complicated than that. The people who want version number names in the release downloads are not going to be content with having that for source code only - they are also going to want it for the precompiled binaries. So I'll have to rename all of those as well. And adjust the scripts that generate the download pages, etc. Since this is a major change, I propose that it be deferred until Fossil 2.0 (which will likely be the next release). - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU7PFdAAoJELtYwrrr47Y4DAgH+QGwXmn8hA1PopVf6QaLfN4f 1qrzlSHX9BfdZJq5rNudvJMcg9GM2Bv6TKrHYUvny/m8OJHpToEV74NzvriRQwES C3YWesphl54ZrKXdLw/GqUspKRXF18feg2eTVkh2smrYgExNpXi0rJLHjdw9AjQh DiKHWq9qG+OZEtx54ALHZrYnQPtUS+rpWVTczQ7oWdp1wUtXQAPoybL3YDdMvdd4 uf1J/aWWiK1Fm7u8V86TWSkWAZHSqq0jzYVsfkdOzk87NUtnrgAMGFY6LO3JNbN9 8OlFW7Nftc2T8k0BVywudm388hZcWOL/vG897hJPot4Gu2dbQ+zlwnl48UPM6Lk= =daCa -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On 2/24/15, Ron W ronw.m...@gmail.com wrote: [Managers] associate dates with deadlines, so version numbers remove a source of panic. Fair enough. I'll migrate from dates to version numbers in the next release. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 7:01 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp d...@sqlite.org wrote: So it seems like having dates on the download would be more meaningful than having a made-up version number. No? With a date, at least you know about how old the code is. What information does a made-up version number provide? How is that better than a date? FWIW, that's the approach i've taken for all but one of my own projects the past 15 years. Version numbers, _unless_ they are accompanied by a strict set of compatibility rules involving API- and/or binary compatibility, are _absolutely meaningless_. For the SW I work on, the version number has a well defined set of features and fixes. A number rather than a date/time because that's easier for the project managers to keep track of in their spreadsheets (they associate dates with deadlines, so version numbers remove a source of panic). Also, remove a source of confusion: I thought I just built the software in this module, but the date in it is from last week. (We do, however, have internal version numbers on certain data structures, such as calibration data. This insures that, for example, a given calibration file is compatible with the SW in the module. When the structure is changed, the version number gets incremented. This allows us to not have to regenerate calibration files for every SW release.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On 24 February 2015 at 16:50, Ron W ronw.m...@gmail.com wrote: On Tue, Feb 24, 2015 at 7:01 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp d...@sqlite.org wrote: So it seems like having dates on the download would be more meaningful than having a made-up version number. No? With a date, at least you know about how old the code is. What information does a made-up version number provide? How is that better than a date? FWIW, that's the approach i've taken for all but one of my own projects the past 15 years. Version numbers, _unless_ they are accompanied by a strict set of compatibility rules involving API- and/or binary compatibility, are _absolutely meaningless_. For the SW I work on, the version number has a well defined set of features and fixes. A number rather than a date/time because that's easier for the project managers to keep track of in their spreadsheets (they associate dates with deadlines, so version numbers remove a source of panic). Also, remove a source of confusion: I thought I just built the software in this module, but the date in it is from last week. (We do, however, have internal version numbers on certain data structures, such as calibration data. This insures that, for example, a given calibration file is compatible with the SW in the module. When the structure is changed, the version number gets incremented. This allows us to not have to regenerate calibration files for every SW release.) For my day job, version numbers in ANY capacity are out of the equation (NOT my choice). The project in question either in trunk/head or its in some branch. It pretty much means filing bug reports are useless since we can't really identify when an issue first occurred. I'd be happy for a version number, svn rev number, or a date in my work's product. Too bad it's not my decision to change this, although I've filed a bug report to have it included. ;) -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp d...@sqlite.org wrote: So it seems like having dates on the download would be more meaningful than having a made-up version number. No? With a date, at least you know about how old the code is. What information does a made-up version number provide? How is that better than a date? FWIW, that's the approach i've taken for all but one of my own projects the past 15 years. Version numbers, _unless_ they are accompanied by a strict set of compatibility rules involving API- and/or binary compatibility, are _absolutely meaningless_. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 4:47 PM, Andy Goth andrew.m.g...@gmail.com wrote: So just grab the file at this URL: https://www.fossil-scm.org/fossil/tarball/fossil-1.31.tar.gz?uuid=version-1.31 and be happy. The file will have the name you want. Or replace 1.31 with whichever tagged release you desire. The feature you want already exists. That wasn't what Mr robotanarchy was asking for. He was referring the the files made available on the Downloads page, which appeal to be pre-made: https://www.fossil-scm.org/download/fossil-src-20150223162734.tar.gz which looks like a link to a static file rather than a request to generate a tar file. Some people consider such pre-made tar files to be the official release packages. Also, pre-made tar files have the advantage of imposing a lessor laod on the server. Otherwise, the on-the-fly-generated tar file is equivalent. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil source download naming scheme
On Tue, Feb 24, 2015 at 5:16 PM, Richard Hipp d...@sqlite.org wrote: It's going to be more complicated than that. The people who want ... Since this is a major change, I propose that it be deferred until Fossil 2.0 (which will likely be the next release). Honestly, it doesn't matter to me. Mr robotanarchy made the request and I injected my observations. I just download, build, install, fossil rebuild and forget. I like that I don't have to hassle with Fossil. As long as it works and is helpful in doing my main work, I'm content with it. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
