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
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
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
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
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
___
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
-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
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
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.
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
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:
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
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
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]
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
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
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
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.
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/
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
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
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.
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
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
___
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
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
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
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
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.
29 matches
Mail list logo
