Hi Mercury,
> 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
(And "The date" means the date, when a version was released by its
developer, not the upload date to Ibiblio.)
> - 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.
There also already is FreeDOS kernel *2042*.
> - Two digits for the major version
You mean "minor" here, I think.
> - Two digits for the revision
In general, these are four digits sometimes.
> - 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"?
> - 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
> Note that there is no program name at all in the individual archives -
> the parent folder has that instead. Programs which simply use the date
> as their version number would leave the version field as "000000". Also,
> in my opinion, the package type (A, B, or S character ) could be omitted
> since every archive should have all components - all source code, all
> binaries, all documentation, etc. It should be up to the
> installer/archiver to only extract what the user requests from the archive.
For an online repository that would be okay, but not for the distros.
Space on physical media is still limited.
> The only drawback (if you can call it that) with this specification is
> that the resulting filenames are most definitely /*not*/ 8.3 compliant.
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.
> My fix for that - that is, if we even care about this issue - would be
> to have one ZIP for each application, then have all versions of that
Hopefully all package names fit in 8 chars. ;-)
> program in that single ZIP. I know, I know, that doesn't make it easy to
> download a single version, but is that really an issue since the
> majority of our applications are so tiny to begin with? Also, doing so
> would allow archivers to achieve a much higher compression ratio, and
> ultimately saving space in the end.
That might be the solution for many packages.
> This concludes my feedback on the issue :) I'm interested to hear
> everyone else's thoughts on this as well.
That's all for now.
By the way: Is a full-quote top posting plus embedding a screenshot
really necessary?
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
