| |||||||||||||
Large version numbersLarge version numbersPosted Nov 9, 2011 3:32 UTC (Wed) by stevenj (guest, #421)In reply to: Large version numbers by codewiz Parent article: Firefox 8 released
3.9 and 39 do not merely differ by a decimal point, because 3.9 does not represent a single number. A minor upgrade to 3.9 is 3.10, whereas going from 39 to 40 makes no such distinction. The general point is that major.minor.bugfix numbers are triples of numbers, each of which conveys its own technical meaning, not merely arbitrary placements of two decimal points in a single integer. In analogy to your question, I could ask: Why write dates as year-month-day? Why not simply count days from some arbitrary starting point?
(Log in to post comments)
Large version numbers Posted Nov 9, 2011 3:38 UTC (Wed) by pr1268 (subscriber, #24648) [Link] > Why write dates as year-month-day? Why not simply count days from some arbitrary starting point? Firefox version 2455874.44
Large version numbers Posted Nov 9, 2011 4:32 UTC (Wed) by codewiz (subscriber, #63050) [Link]
> A minor upgrade to 3.9 is 3.10, whereas going from 39 to 40 makes no such distinction.
Just like in the kernel development model, Firefox releases happen every N months. There are no "major" updates, just time-based releases which include whatever features were ready in time for integration.
Most Linux distributions work this way, which is why we have Fedora 16 and RHEL 6. The yy.mm numbering scheme used by Ubuntu and OpenSUSE does not have anything to do with major and minor releases.
> In analogy to your question, I could ask: Why write dates as year-month-day?
Indeed, that's an unnecessary complication originated when the motion of celestial bodies was attributed to divine will and incomplete astronomical knowledge. Still, dates expressed in yy-mm-dd format have at least some relationship with actual cycles of our planet. What would a major.minor version scheme mean in the context of Firefox's time-based releases?
Large version numbers Posted Nov 9, 2011 8:21 UTC (Wed) by ekj (guest, #1524) [Link]
Precisely. A year is *actually* 365.24 days (give or take). And a day is *actually* as long as it is. And a moon-cycle is *actually* as long as it is, allthough that has little practical significance. (and doesn't match the "month" anyway)
But sure, we could use year day.fraction and do away with months, weeks, hours, minutes and seconds.
2011 150.5 would be mid-day on the 150th day of year 2011.
Large version numbers Posted Nov 9, 2011 12:47 UTC (Wed) by robbe (guest, #16131) [Link]
Multi-part dates (or version numbers, to give some semblance of being on-topic) seem to be easier to parse than unstructured ones.
Quick: if I invite you to an outdoors event on 2012 day 222, will you need to bring your jacket? I guess we could start to remember key day numbers (e.g. "frost recedes around 74", "324 is our anniversary"), but I think we more easily remember day-month combinations than three-digit numbers.
The days-since-the-epoch scheme is insane.
Large version numbers Posted Nov 9, 2011 12:59 UTC (Wed) by ekj (guest, #1524) [Link]
I dunno about that. you can skip the last digit in the year if you care only about season, you're thus left with 36 10-day periods, I guess that granularity is a little high, but I don't think it's a *lot* harder.
Do you need a jacket for an event at 22/36 of a year isn't much harder than Do you need a jacket for an event at 8/12 of a year which is the current system.
Multi-part version-number can confuse too; I've seen several people be confused about what is better: 2.27 and 2.3 if you read them as decimals, you'll end up thinking that 2.3 is the higher number thus the newest version.
|
|||||||||||||