[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NGO] external module properties
>>>>> On Tue, 29 Apr 2008 15:05:39 -0400, Phil Shafer <phil at juniper.net> said:
PS> Then I'm lost. You wanted:
PS> (a) required formatting
PS> (b) sortability
PS> Which requirement doesn't YANG satisfy?
I actually said that I didn't (ideally) want (a). The requirement on
formatting I suggested was a simple sortable number (either integer or
floating point) who's value could be left to the module writer as long
as it was either an integer or float.
I'm fine with a date and time too, though. This is not an argument that
I think is crucial, mind you, but I don't see the point in restricting
modules to only be released once per day. That's imposing an arbitrary
rule that isn't needed. And letting the version spec be either a
integer or float without additional imposed semantics means you can use
a date-based number or you don't have to. Flexibility all around.
>> revision 20070609 {
>> revision 200706090001 {
>> revision 42 {
>> As long as future > past, the tools should be happy.
PS> This breaks (a) above.
Which I never said I wanted. You extrapolated that from my desire for an
sortable format. It's easy to see how you could have thought that and
I'm sorry if I didn't explain it well enough.
PS> There's a lot to be gained by using dates
What?
PS> Being able to look at the revision history and see when what
PS> happened, how stable a module is, and how likely folks are to be
PS> up-to-date with the latest version is important.
So you want to compare the frequency of releases based on the date to
decide whether to use it or not?
PS> And it avoids tons of discussion about whether we need two or three
PS> decimal numbers and when the major or minor version should change.
PS> It's simple, obvious, sortable, well-defined, and will last for
PS> thousands of years.
How about 2008-01-01-0000? Or better (IMHO) 200801010000 which is
instantly machine parse-able without special code? Or how about an XML
defined date/time string that leaves the time stamp as optional?
Wouldn't that provide the most reuse and flexibility?
--
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo