0

For example, on nuget.org there are these preview packages published for System.Text.Json:

6.0.0-rc.2.21480.5  
6.0.0-rc.1.21451.13 
6.0.0-preview.7.21377.19
6.0.0-preview.6.21352.12
6.0.0-preview.5.21301.5
6.0.0-preview.4.21253.7
6.0.0-preview.3.21201.4
6.0.0-preview.2.21154.6
6.0.0-preview.1.21102.12

I get the 'preview.n' and 'rc.n' parts. I believe these relate to the wider .NET releases.

I wondered if the third number is number of days since some baseline date, but that doesn't seem to be consistent (based on subtracting that number from publication date you get different baseline dates); if it was then I would have guessed the fourth number to be the build number within a given day.

I ask because I am interested in understanding what package versioning strategies are in use in the wild, and whether there is anything to be learned from this scheme in use by Microsoft.

redcalx
  • 8,177
  • 4
  • 56
  • 105
  • I think the 21 part is the year. However, the last 3 digits go above 365/366, so that isn't an intra year day number. – redcalx Oct 28 '21 at 14:24
  • It's possible the 5 digit number is a build or flight number, but then I have no idea what the final field is. Since it's open source, you might be able to find the script that produces that string. – jwdonahue Nov 03 '21 at 04:55
  • @jwdonahue Note that the '21' part seems to correspond to the year, i.e. if you compare the number with the nuget release date. And the following 3 digits seem to reset each year. My current theory is that the 3 digits represent how many half days starting at Jan 1st, and the last two after the dot are number of builds within that half day (?!) – redcalx Nov 03 '21 at 17:49
  • Even a broken clock shows the correct time twice per day. It may be the year, or it's just the higher order digits in a build number. My vote is on the build number theory, because Microsoft embeds them in everything. All the rest is just labelling of some kind. – jwdonahue Nov 03 '21 at 19:22

0 Answers0