plans for 0.0.6 release

[Rusty Russell]

On Sat, 2005-06-04 at 11:54 +1000, Martin Pool wrote: 
> On  3 Jun 2005, Rusty Russell <rusty at rustcorp.com.au> wrote:
> > On Wed, 2005-06-01 at 10:39 -0500, Nicholas Nethercote wrote:
> > > - I think the "to" syntax is horrid -- ambiguous and thus error-prone both
> > >    to implement and use, and inconsistent with every other command line
> > >    option in the universe.  "4 to 5" might look nice and Python-ish, but
> > >    Python-style syntax doesn't mix well with shell syntax.
> > > 
> > > - I think using '-' as a range operator is bad.  '-' is already used
> > >    to introduce options (ie. -r), and also in some revision names, so why
> > >    overload it with another meaning?  It just makes command lines harder to
> > >    parse (for humans and machines).  I mentally parse "-r4-5" as "-r4 -5".
> 
> A worse case is '-r-4' vs '-r -4'.

Yes, but:
1) -r-4 is silly.  You always know the lower bound, it's 1.
2) -r -4 is silly because if we go the namespace route, it's -r last:4

> > We went down the ":" path in netfilter for port ranges, and I've
> > regretted it ever since.
> 
> It seems it's particularly confusing there because colon is already
> mentally associated with HOST:PORT syntax.  Do you think that's the main effect?

Not really, it's used as "iptables -A FORWARD -p tcp --ports 1:4".
Colon was used because ports referred to by names can have "-" in them,
but in the vast majority of cases it just irritates newbies.

> > It is the most common mistake I make in
> > writing rules.
> 
> What happens?  You write 20-21 when you should say 20:21?

Yes.

> > There is no parsing ambiguity when combined with the "<namespace>:"
> > syntax, which I think everyone quite likes.
> > 
> > > - I quite like ':' as a range operator, it works fine in Subversion.  But
> > >    if ':' has another use in revision names, then avoiding overloading
> > >    it is a good idea.
> > 
> > : has merit because it is used in CVS and svn.  CVS also uses :: to
> > indicate a collapsed range in some cases.  Two -r options are used in
> > RCS.  
> 
> Two -r options would nicely avoid the debate, and they've been
> proposed in some patches.  I think the main drawback is they can't
> distinguish "20-" and "-20" and "20".

"-r 20 -r now", "-r last:20" and "-r 20"?

> On the whole I think '-r A-B' is right, perhaps with ':' supported
> where it doesn't clash with the prefix form for dates and so on.

But how do you parse this?
	-r tag:my-tag-name-tag:20

Banning "-" in tag names is probably not a good idea (banning anything
in tag names is probably not a good idea, because of
internationalization).

I think the parser should be flexible in what it accepts, but there must
be a canonical form for eg. scripts to use which guaranteed protection
against people who create a tag called "tag:tag:-20.. to 7"!

I can have a go at writing something if you want, but it'll be much
slower than someone else doing it.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman