* Ben Hutchings b...@decadent.org.uk, 2011-04-23, 15:06:
[...]
=== version, strings longer than 30 (unique ones) ===
0.9.15+post20100705+gitb3aa806-2
0.0.0+git20091215.9ec1da8a-2+b2
1.0.0~alpha3~git20090817.r1.349dba6-2
1:2.5.0~alpha4+svn20091009-1+b2
2.1.14+2.6.32.13-201005151340-1
Hi,
On Wed, Apr 27, 2011 at 03:11:14PM -0300, Henrique de Moraes Holschuh wrote:
On Tue, 26 Apr 2011, Uoti Urpala wrote:
...
It is still not a good reason to waste part of a draconian 30 chars of space
with hash information.
I agree.
Anyway, I think 30 should be the absolute upper limit for
Osamu Aoki dijo [Thu, Apr 28, 2011 at 11:55:48PM +0900]:
(...)
1.2.10~YYMMDD for prerelease of version 1.2.10
1.2.10~rcYMMDD for prerelease of version 1.2.10 (alternative format)
this last 2 are mostly used in unstable/testing only. So length is
less of problem.
Remember that
Henrique de Moraes Holschuh hmh at debian.org writes:
I do think you misunderstood my point in the hash issue. My point is not
that a full hash will not collide. The point is that the full hash as seen
in a tree received from the upstream DVCS should not see colisions, because
the collision
On Sat, Apr 23, 2011 at 06:31:38PM +0900, Osamu Aoki wrote:
Hi,
In order to manage package file name length below 90 and to have sane
screen for package management, may I suggest to recommend some limits
(for lintian check etc.):
* package name string should be less than 40 characters.
*
On Tue, Apr 26, 2011 at 07:31:22PM -0400, James Vega wrote:
On Tue, Apr 26, 2011 at 10:28:07PM +0900, Osamu Aoki wrote:
In this sense, most reasonable solution seems to me
0.YYMMDD
This way, when ever upstream decide to release package with sane
versioning (usually bigger than 1.)
On Tue, Apr 26, 2011 at 07:31:22PM -0400, James Vega wrote:
Why assume the first version will be = 1.x? It's not uncommon to use
0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
needing an epoch if/when upstream starts using actual version numbers.
~ sorts after ., so
Jon Dowland j...@debian.org (27/04/2011):
~ sorts after ., so 0~110427 will be considered newer than 0.1.
Therefore, the 0 in 0~YYMMDD is meaningless, and would be no better
than ~YYMMDD (which would still sort after 0.1, and require an
epoch).
$ dpkg --compare-versions 0~110427 '' 0.1 echo
On Wed, Apr 27, 2011 at 04:09:48PM +0100, Jon Dowland wrote:
~ sorts after ., so 0~110427 will be considered newer than 0.1.
Therefore,
the 0 in 0~YYMMDD is meaningless, and would be no better than ~YYMMDD (which
would still sort after 0.1, and require an epoch).
From Policy [1], ~ sort
On Tue, 26 Apr 2011, James Vega wrote:
Why assume the first version will be = 1.x? It's not uncommon to use
0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
needing an epoch if/when upstream starts using actual version numbers.
The 0.DATE thing is from before we had support
On Tue, 26 Apr 2011, Uoti Urpala wrote:
This branch of the thread was NOT about packages that use date ONLY. Maybe
that's what you were confused about above? The version would still need the
last release name too, as in 15.3.2~rc3+svn2005010112.
The two possibilities showed up in the
On Tue, 26 Apr 2011, Uoti Urpala wrote:
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're
On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
On Tue, 26 Apr 2011, Chow Loong Jin wrote:
On 26/04/2011 01:50, Gunnar Wolf wrote:
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at,
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Uoti Urpala wrote:
Using date and time as a version is not current best practice. You'll still
need the upstream version part too to sort correctly relative to released
versions.
I was refering to the full commit
On Tue, Apr 26, 2011 at 10:28:07PM +0900, Osamu Aoki wrote:
In this sense, most reasonable solution seems to me
0.YYMMDD
This way, when ever upstream decide to release package with sane
versioning (usually bigger than 1.) within 8 chars and we can continue
without epoch. But this is
Ben Hutchings dijo [Sun, Apr 24, 2011 at 04:54:46AM +0100]:
If you use git describe, removing hashes is a bad idea.
They are needed to identify the version. Version numbers that are not
unique are worthless.
If versions are not ordered without the inclusion of a commit hash, they
are
On 26/04/2011 01:50, Gunnar Wolf wrote:
[...]
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at, mid-devel-cycle
breakage should be at a minimum. So, instead of basing our packages
off arbitrary commit hashes, why not
On Tue, 26 Apr 2011, Chow Loong Jin wrote:
On 26/04/2011 01:50, Gunnar Wolf wrote:
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at, mid-devel-cycle
breakage should be at a minimum. So, instead of basing our packages
On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
[...]
Then, you use UTC date+time, that's two digits for the
best-practice leading of 0., plus 13 digits for MMDDTHHMM,
which is quite precise enough most of the time. Add two more for
seconds, and it is almost
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the
On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote:
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of
On Mon, Apr 25, 2011 at 10:29:53PM +0100, Ben Hutchings wrote:
On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote:
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
If versions are not ordered without the inclusion of a commit hash, they
are not ordered *with* it (except
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're being silly.
All you need is the proper date and time to use as a version (for
ordering), and a proper
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're being silly.
All you need is the proper date
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered,
This seems like an
[Followup-To: nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern tr...@philkern.de schrieb:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff j...@inutil.org wrote:
Given that wheezy will probably be the last version that's strictly
greater than lenny and squeeze we should switch to Debian version
numbers in the version instead of
* Philipp Kern [2011-04-24 10:23 +]:
(OTOH it needs to be greater than +squeeze then, so +debXY won't do.)
It needs to be greater than +squeeze, smaller than . and must not
contain -.
/usr/bin/ascii prints:
|Dec Hex
| 43 2B +
| 44 2C ,
| 45 2D -
| 46 2E .
,debXY would do, but would require
[ dropping debian-cd@ from CC ]
On 2011-04-24 11:59, Philipp Kern wrote:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff j...@inutil.org wrote:
Given that wheezy will probably be the last version that's strictly
greater than lenny and squeeze
On Sun, 24 Apr 2011, Moritz Mühlenhoff wrote:
[Followup-To: nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern tr...@philkern.de schrieb:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at
Hi,
In order to manage package file name length below 90 and to have sane
screen for package management, may I suggest to recommend some limits
(for lintian check etc.):
* package name string should be less than 40 characters.
* version name string should be less than 30 characters.
On Sat, 2011-04-23 at 18:31 +0900, Osamu Aoki wrote:
[...]
=== version, strings longer than 30 (unique ones) ===
0.9.15+post20100705+gitb3aa806-2
0.0.0+git20091215.9ec1da8a-2+b2
1.0.0~alpha3~git20090817.r1.349dba6-2
1:2.5.0~alpha4+svn20091009-1+b2
2.1.14+2.6.32.13-201005151340-1
Ben Hutchings b...@decadent.org.uk (23/04/2011):
I would like to see policy forbid the use of commit hashes in
versions. They aren't ordered, and the information about exactly
which commit the snapshot was can be included in the changelog.
I'll be happy to second any wording you could come up
On Sat, 23 Apr 2011, Cyril Brulebois wrote:
Ben Hutchings b...@decadent.org.uk (23/04/2011):
I would like to see policy forbid the use of commit hashes in
versions. They aren't ordered, and the information about exactly
which commit the snapshot was can be included in the changelog.
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered,
This seems like an odd reason to forbid them; should one also
forbid strings such as 'pre', 'rc', 'lenny', 'squeeze' in version
numbers
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the information about exactly which commit the
snapshot was can be included in the changelog.
If you use git describe, removing hashes
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the information about exactly which commit the
snapshot was can be included
37 matches
Mail list logo
