Re: [NGO] external module properties

Wes Hardaker writes:
>>> I'd be tempted not to even define the required formatting of the version
>>> number.  Simply say it must be sortable using a standard comparison
>>> function (strcmp or >).
>Good start, but I'm going to take issues with only using a date.  And
>YANG doesn't do what I said.  It specifies the revision number format as
>a date.

Then I'm lost.  You wanted:
(a) required formatting
(b) sortability
Which requirement doesn't YANG satisfy?

>I wanted to be able to pick what was right for me, as an author, from
>any of these (for only I know what is good from my authoring
>perspective):

It's a standard.  You give up "right for me" for a common structured
standard.

>  revision 20070609 {
>  revision 200706090001 {
>  revision 42 {
>As long as future > past, the tools should be happy.

This breaks (a) above.

There's a lot to be gained by using dates and not a lot of down
side.  Being able to look at the revision history and see when what
happened, how stable a module is, and how likely folks are to be
up-to-date with the latest version is important.  And it avoids
tons of discussion about whether we need two or three decimal numbers
and when the major or minor version should change.  It's simple,
obvious, sortable, well-defined, and will last for thousands of
years.

Thanks,
 Phil
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo