* Ben Hutchings , 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
1:2.2cvs20100105-true-dfsg-5+b1
0
Henrique de Moraes Holschuh 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 wo
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 w
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 fo
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 thr
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 suppor
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], ~
Jon Dowland (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 "Jon
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 "0~1
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 big
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 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
Henrique de Moraes Holschuh 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 comm
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
On Tue, 26 Apr 2011, Uoti Urpala wrote:
> Henrique de Moraes Holschuh 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 yo
Henrique de Moraes Holschuh 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 da
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 de
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
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
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 th
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 alm
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 pa
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, wh
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
On Sun, 24 Apr 2011, Moritz Mühlenhoff wrote:
> ["Followup-To:" nach gmane.linux.debian.devel.general gesetzt.]
> Philipp Kern schrieb:
> > ["Followup-To:" header set to gmane.linux.debian.devel.general.]
> > On 2011-04-23, Dominic Hargreaves wrote:
> >> On Sat, Apr 23, 2011 at 03:06:39PM +0100,
[ 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 wrote:
> >> Given that wheezy will probably be the last version that's strictly
> >> greater than lenny and squeeze we sho
* 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
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff 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 codenames post-s
["Followup-To:" nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern schrieb:
> ["Followup-To:" header set to gmane.linux.debian.devel.general.]
> On 2011-04-23, Dominic Hargreaves wrote:
>> On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
>>> I would like to see policy forb
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves 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 odd rea
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 in
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 ha
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 al
On Sat, 23 Apr 2011, Cyril Brulebois wrote:
> Ben Hutchings (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 t
Ben Hutchings (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 with on that
topi
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
> 1:2.2
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.
(securit
37 matches
Mail list logo
