> On Sun, Dec 01, 2024 at 09:44:17PM -0800, Otto Kekäläinen wrote:
> > My intent here was to suggest specifically that the version of form
> > 0.0~git20130606.b00ec39-1 would be elevated as the Policy recommended
> > form, as it makes sense and is already most popular.
>
> For the record, I assume
On Sun, Dec 01, 2024 at 09:44:17PM -0800, Otto Kekäläinen wrote:
> My intent here was to suggest specifically that the version of form
> 0.0~git20130606.b00ec39-1 would be elevated as the Policy recommended
> form, as it makes sense and is already most popular.
For the record, I assume it's most p
On Sun, Dec 01, 2024 at 09:44:17PM -0800, Otto Kekäläinen wrote:
> My intent here was to suggest specifically that the version of form
> 0.0~git20130606.b00ec39-1 would be elevated as the Policy recommended
> form, as it makes sense and is already most popular.
For the record, I assume it's most p
Hi,
> This would not constitute any sort of rejection for which maintainers of
> packages would need to be concerned. It does not mean anyone's
> practices should change.
>
> It does not mean that there is no policy (lowercase 'p') for these
> version strings in Debian.
What I am trying to expre
Hello,
On Sun 01 Dec 2024 at 06:53pm -08, Otto Kekäläinen wrote:
> Please no. Rather close it and state that you do not accept this in
> the policy so that there is an audit trail that this was rejected from
> policy and who made the decision.
>
> Updates/changes elsewhere can then refer this bug
> > On Wed, Nov 27, 2024 at 01:11:14PM -0800, Otto Kekäläinen wrote:
> >> Package: debian-policy
> >> Found: 4.7.0.1
> >>
> >> I would like to suggest the Debian Policy to recommend a specific
> >> Debian package version string scheme in cases where upstream has no
> >> releases, but they do have g
Hello,
On Sun 01 Dec 2024 at 04:18pm +01, Tobias Frost wrote:
> On Wed, Nov 27, 2024 at 01:11:14PM -0800, Otto Kekäläinen wrote:
>> Package: debian-policy
>> Found: 4.7.0.1
>>
>> I would like to suggest the Debian Policy to recommend a specific
>> Debian package version string scheme in cases whe
On Wed, Nov 27, 2024 at 01:11:14PM -0800, Otto Kekäläinen wrote:
> Package: debian-policy
> Found: 4.7.0.1
>
> I would like to suggest the Debian Policy to recommend a specific
> Debian package version string scheme in cases where upstream has no
> releases, but they do have git commit ids to refe
On Wed, 27 Nov 2024 at 13:11:14 -0800, Otto Kekäläinen wrote:
> In case your upstream does not use version numbers, the Debian package
> version will look like this: 0.0~git20130606.b00ec39-1
Is there a reason to use 0.0 here in preference to just 0?
(For example see src:darkplaces, src:openjk)
>
"Diederik de Haas" writes:
> On Sun Dec 1, 2024 at 1:09 PM CET, Simon Josefsson wrote:
>> "Diederik de Haas" writes:
>>
>> >> In case you make more than one snapshot per day, you can append a
>> >> snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
>> >> This should rarely be nece
On Sun Dec 1, 2024 at 1:09 PM CET, Simon Josefsson wrote:
> "Diederik de Haas" writes:
>
> >> In case you make more than one snapshot per day, you can append a
> >> snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
> >> This should rarely be necessary.
> >
> > If a rule is proposed
On Thu, Nov 28, 2024 at 10:44:40AM +0100, Simon Josefsson wrote:
> Otto Kekäläinen writes:
>
> >> The commit hash. 007c9af.
> >
> > OK, thanks.
> >
> > I disagree here - to me the git commit hash is the single most
> > important identifier for the software version if there are no actual
> > relea
On Sun, 01 Dec 2024 12:58:41 +0100 Jonas Smedegaard wrote:
> On Thu Nov 28, 2024 at 10:44 AM CET, Simon Josefsson wrote:
> > In case you make more than one snapshot per day, you can append a
> > snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
> > This should rarely be necessary.
"Diederik de Haas" writes:
>> In case you make more than one snapshot per day, you can append a
>> snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
>> This should rarely be necessary.
>
> If a rule is proposed to Policy, then it needs to account for such a
> situation and should
On Thu Nov 28, 2024 at 10:44 AM CET, Simon Josefsson wrote:
> In case you make more than one snapshot per day, you can append a
> snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
> This should rarely be necessary.
I have tried this approach, and ended in situations where the git h
15 matches
Mail list logo