On Monday, May 10, 2021 1:00 PM, Robert Riebisch r...@bttr-software.de wrote:
> Hi Mercury, Hello there! > > I'd say we really /do/ need a set standard for versioning. The > > frustration Eric mentioned in his email has hit me once or twice as well > > when combing through archives to compare versions. > > The format I propose is: > > > > - The date in ISO 8601 format > > ISO 8601 has various formats. You specifically mean: YYYYMMDD I wasn't aware it has various formats, but yes -Â YYYYMMDD specifically. > (And "The date" means the date, when a version was released by its > developer, not the upload date to Ibiblio.) Correct, the date of the version's release. > > - Two digits for the major version > > There probably will be some software needing three digits. Firefox, > although not available for (Free)DOS), is already at version 88.0. Right, but I was basing this on the majority of FreeDOS software which jumps to mind. I don't think we have any applications which are quite so liberal with their version numbering. A side note/gripe here: Traditionally (at least the way I have learned it) you only increment the major version when making a major change to the application - e.g. changing the structure of files saved by the application or perhaps a major overhaul of how things work internally. With that in mind, how, pray tell, could Firefox possibly be at 88.0? Mozilla, do you mean to tell me you made sweeping, application-wide changes eighty eight times? I think not lol :) > There also already is FreeDOS kernel 2042. Gah, ok you got me there. I hadn't thought of the kernel at all. Off the top of my head, though, I'm not certain; is 2042 a version number in and of itself or just a revision/build number? > > - Two digits for the major version > > You mean "minor" here, I think. Correct, I did mean to say minor. > > - Two digits for the revision > > In general, these are four digits sometimes. Good point. Now that you mention it, since many applications use a short integer for their revision/build number, this in theory could yield version numbers up to five digits long. Perhaps that would be a better choice for future-proofing? Or would that be overkill? > > - A character for the packaging identifier (this would be changed in > > cases where the packaging of the application has changed but the > > application itself has not) > > > > Your screenshot doesn't include such an example. > Would that be "20210510-010101-a-b"? Yes, exactly. I haven't yet decided on whether to leave this blank when there's no package identifier or to make everything default to "a". I'm leaning towards the latter. > > - A character for the type of archive (Perhaps something like: a = All, > > b = Binary only, s = Source only) > > > > - Hyphens between all fields for clarity > > > > > > For the hypothetical application /GeeWhiz/, this would give us the > > following structure: > > GeeWhiz > 20180117-010001--b > 20180117-010001--s > 20190202-010002--b > 20190202-010002--s > 20201110-010005--b > 20201110-010005--s > 20210509-010100--b > 20210509-010100--s > For computers that's easy to read, but for humans? > How about that, if we already break 8.3? > 2018-01-17_01.00.01__b > 2018-01-17_01.00.01__s > 2019-02-02_01.00.02__b > 2019-02-02_01.00.02__s > 2020-11-10_01.00.05__b > 2020-11-10_01.00.05__s > 2021-05-09_01.01.00__b > 2021-05-09_01.01.00__s > With 3 or 4 digits for the version numbers: > 2018-01-17_001.000.0001__b > 2018-01-17_001.000.0001__s > 2019-02-02_001.000.0002__b > 2019-02-02_001.000.0002__s > 2020-11-10_001.000.0005__b > 2020-11-10_001.000.0005__s > 2021-05-09_001.001.0000__b > 2021-05-09_001.001.0000__s > Or in condensed layout, if sorting by date is enough: > (Then the number of digits for the version numbers doesn't matter.) > 2018-01-17_1.0.1__b > 2018-01-17_1.0.1__s > 2019-02-02_1.0.2__b > 2019-02-02_1.0.2__s > 2020-11-10_1.0.5__b > 2020-11-10_1.0.5__s > 2021-05-09_1.1.0__b > 2021-05-09_1.1.0__s Yes, that could work also. Accepting that, I would take it a step further and simply use spaces between the fields: 2018-01-17 001.000.00001a b 2018-01-17 001.000.00001a s 2019-02-02 001.000.00002a b 2019-02-02 001.000.00002a s 2020-11-10 001.000.00005a b 2020-11-10 001.000.00005a s 2021-05-09 001.001.00000a b 2021-05-09 001.001.00000a s I find it more intuitive to leave the fields expanded so that the numbers easily flow visually, not to mention it would make for easier code writing if the programmer knew the same range of characters would represent the same piece of data in every package name. Also, on the odd chance an author has two versions come out in a single day (some bug fixes happen fairly fast) then condensing puts us right back in the same boat. For these reasons, I vote no on condensing. But that's just me. :) > > ... > > For an online repository that would be okay, but not for the distros. > Space on physical media is still limited. Web archiving is the primary use case I have in mind for this standard, but in the case of physical media, the extra items - both previous versions and source code alike - could easily be stripped out according to the needs of the media. > > ... > > Indeed, but I don't care about that any longer, because all my Internet > downloading for DOS is done on machines supporting LFNs, i.e., Windows. Agreed, I also don't think this matters that much these days. > ... > Hopefully all package names fit in 8 chars. ;-) Here's hoping! lol > ... > That's all for now. > ... Thanks for the feedback! _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
