Hi Mercury, >> > - 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 :)
https://semver.org/ also explains a versioning concept. But as every developer is free to chose "his" concept, looking for the perfect concept (= One that fits all.), is like looking for the holy grail. >> > - 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? Five digits would only be overkill, if you decide to put leading zeros to package filename. ;-) >> > - 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. I'm would be fine with the latter. But there are already packages with a trailing character to identify different versions, where NOT only the packaging changed. For example: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mem/old/1.2/ Of course, we could turn the "b", "c", ..., into numerical equivalents, e.g., mem12b.zip -> mem122.zip (= version 1.2.2). But this would make referencing to specific packages (existing docs or mails) more complicated and probably requires "translation tables". >> 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 disagree to use spaces, because it requires quoting or encoding in URLs. It's also a matter of personal taste. > 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. :) To me expanded fields are harder to follow visually, just because there are more digits on the screen. We could avoid this by using even more spaces: 2019-02-02 1. 0. 2a b 2019-02-02 1. 0. 2a s 2020-11-10 1. 0. 19a b 2020-11-10 1. 0. 19a s 2021-05-09 1. 1. 0a b 2021-05-09 1. 1. 0a s *lol* Hyphens instead: 2019-02-02 --1.--0.----2a b 2019-02-02 --1.--0.----2a s 2020-11-10 --1.--0.---19a b 2020-11-10 --1.--0.---19a s 2021-05-09 --1.--1.----0a b 2021-05-09 --1.--1.----0a s Hyphens and back to my underscores: 2019-02-02_--1.--0.----2a_b 2019-02-02_--1.--0.----2a_s 2020-11-10_--1.--0.---19a_b 2020-11-10_--1.--0.---19a_s 2021-05-09_--1.--1.----0a_b 2021-05-09_--1.--1.----0a_s Umm... >> 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. I see. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
