Le vendredi 04 novembre 2016 à 10:16 +0100, Ulrich Mueller a écrit :
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote:
>
> >
> > On 11/03/2016 05:11 PM, Michał Górny wrote:
> > >
> > > == Policy changes? ==
> > > I think that the following
On Sat, 5 Nov 2016 12:43:31 +0100
Ulrich Mueller wrote:
> I still don't see why you must (ab)use the revision for that. With
> virtuals, the whole PV is at your disposal, so you could append .5.22
> to it, or even use a suffix like _p522.
Incidentally, I did use _p522 for the one case we had pre
> On Sun, 6 Nov 2016, Kent Fredric wrote:
> So the strategy that I was considering was to "split" each logical
> upstream virtual into several pieces:
> virtual/perl-Foo-N to virtual/perl-Foo-N-r99 : "Always pull perl core/*"
> virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "A
On Sat, 5 Nov 2016 11:13:35 +0100
Ulrich Mueller wrote:
> revision component must not be used for upstream versions:
The problem is we have *2* upstream versions.
virtual/perl-Foo-N
Maps to
perl-core/Foo-N
And
dev-lang/perl-Y ( for possibly more than one value of Y )
And Y does not eq
> On Sat, 5 Nov 2016, Kent Fredric wrote:
>> I would assume to be high enough, even if you use multiples of
>> 100 to label the slot. Or do you expect having more than 100 slots
>> for Perl?
> Well, the desire is for the -r (or similar) part correspond to
> something representative of wh
On Fri, 4 Nov 2016 10:24:28 +0100
Ulrich Mueller wrote:
> I would assume to be high enough, even if you use multiples of
> 100 to label the slot. Or do you expect having more than 100 slots for
> Perl?
Well, the desire is for the -r (or similar) part correspond to
something representative o
> On Fri, 4 Nov 2016, Kent Fredric wrote:
>> 1. Revision number must be no longer than :
>> 1a. to make <=X-r reliable,
>> 1b. to prevent pathological uses of revision as date.
> I think most the arguments you've made for this stem from subjective
> and social problems, not technical
> On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote:
> On 11/03/2016 05:11 PM, Michał Górny wrote:
>> == Policy changes? ==
>> I think that the following new policies could make sense:
>>
>> 1. Revision number must be no longer than :
> You likely mean "no higher than ", longer than wo
On Thu, 3 Nov 2016 17:11:22 +0100
Michał Górny wrote:
> 1. Revision number must be no longer than :
> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.
I think most the arguments you've made for this stem from subjective
and social problems, not technica
On 11/03/2016 05:11 PM, Michał Górny wrote:
> == Policy changes? ==
> I think that the following new policies could make sense:
>
> 1. Revision number must be no longer than :
You likely mean "no higher than ", longer than would give large values
> 1a. to make <=X-r reliable,
> 1b. t
> On Thu, 3 Nov 2016, Michał Górny wrote:
> == Policy changes? ==
> I think that the following new policies could make sense:
> 1. Revision number must be no longer than :
> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.
I think that we should con
On Thu, Nov 3, 2016 at 1:44 PM, Ian Stakenvicius wrote:
> On 03/11/16 01:20 PM, Rich Freeman wrote:
>>
>> Let's just hope nobody starts using tex version numbering and so on.
>> Dates might be used in cases where upstream doesn't publish sane
>> revisions (in fact, texlive versions are dates, albe
On 03/11/16 01:20 PM, Rich Freeman wrote:
> On Thu, Nov 3, 2016 at 12:11 PM, Michał Górny wrote:
>>
>> 1. Revision number must be no longer than :
>> 1a. to make <=X-r reliable,
>> 1b. to prevent pathological uses of revision as date.
>>
>
> Let's just hope nobody starts using tex version
On Thu, Nov 3, 2016 at 12:11 PM, Michał Górny wrote:
>
> 1. Revision number must be no longer than :
> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.
>
Let's just hope nobody starts using tex version numbering and so on.
Dates might be used in cases wh
Hi, everyone.
As part of our work on version operators, we've noticed some issues
with our version policies. ulm has done some additional research on
the topic and now I'd like to open a discussion on our rules.
== PMS rules ==
PMS specifies only minimal syntax for versions, that is allowed type
15 matches
Mail list logo
