Okay, I thought I understood the (relatively) new numbering system for VPS updates. But it’s only Dec. 11th (okay, 12th by now in Europe and elsewhere), and if I’m reading it right we’re currently into week 56? ???
Did I wake up on a strange planet this morning, or something? 
MikeBCda
have you not read about the new “leap weeks” that have been introduced into the calendar?
Or maybe it was just a typo by a rushed avastee.
Well spotted! Maybe we’ll get the real answer.
Oh well, looks like somebody noticed
Let’s say that the previous numbering (week_number-VPS_within_the_week) has been “reinterpretted” as (bigger_update_number-smaller_update_since_the_bigger_one), i.e. the first number isn’t really the week number anymore.
Actually, what I wrote is not even fully right… it’s not necessarily a “bigger update” - the thing is that the differences (in the differential updates) are transfered between the current VPS and the previous XXX-0 one (i.e. not the previous one if it doesn’t end with a zero). So, the more XXX-0 VPS files we release, the smaller the differences, and the smaller the traffic.
The numbering will probably return to “normal” when this year is over.
Or will most probably transform into YYMMDD-v numbering as was suggested in Scavenger docs by Eda.
Sounds much better to me.
Me too 8)
Gets my vote for clarity, a user will know exactly how out of date his VPS update is.
I believe nobody is arguing that it wouldn’t be better for the users; the question is if it’s doable. Even though it doesn’t appear so, the amount of work needed for this change might be quite big (especially for kubecj).
One other objection to YYYYMMDD, even though it sounds great. What happens when things get frantic and there’s two (or more) the same day?
That’s why it’ll be YYMMDD-v, for example 061212-0, 061212-1…
This would be a nice change!
It would be really great