Re: Bug#17621: [PROPOSED]: About versions based on dates
Hi
>>"Joey" == Joey Hess <joey@kitenet.net> writes:
Joey> Manoj Srivastava wrote:
>> Because in this case the version number conveys something
>> beyond just a mere number: and consistency in nomenclature helps
>> developers, and users, to decipher the version.
Joey> Please bear in mind that most people who run into a version
Joey> number that hasq been changed in this way will be inconvienced
Joey> by it - it will not confirm to the upstream version
Joey> number. That's why I think such changes should be made only
Joey> when necessary, not sweepingly.
Remember, this applies to snapshots -- thre are upstream
veeersion dates, as would ours.
>> A policy that spells out how to do this right in the first
>> place shall prevent such mistakes in the future totally.
Joey> No, it will not. In many cases, epochs will need to be
Joey> introduced to make the new version numbering work, that would
Joey> have not been introduced if this change was not made. Your
Joey> argument applies only to new packages.
At least we agree about new packages ;-) About older packages,
I am not sure. I think a single epoch, followed by sane dates, would
not really confuse people, and limit things to just one epoch, and
that having consistent date-formatted names is a big enough win.
Joey> I think an epoch at some time in the future is preferred to
Joey> confusing users about version numbers from day 1.
I do not think humans would be confused, epsecilly if it were
common practice to encode dates in this fashion.
manoj
--
A couple more shots of whiskey, women 'round here start looking good.
[something about a 10 being a 4 after a six-pack? Ed.]
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: