Hi Jim,
>> solution, 2.01, 2.02, 2.11, 2.20. if necessary 2.02.01 for minor updates or:
>> 2-01, 2-02, 2-11, 2-20, 2-02-01. but of course this will run out of 8.3.
>> compared with checking and changing thousands of htm help files renaming is
>> a five minutes job.
>>
>
> Using "2.02.01" is an interesting solution, but then the "version
> number" on the filename no longer matches what's in the documentation
> - or reported by the program when you run it. If the program outputs a
> version number that's "2.1" (and uses "2.1" in the documentation) and
> we rename the file to "2.01" .. that will confuse people too.
You could put a README matching numbers.
> There is no 100% perfect solution. :-(
Yes.
>> and sometimes the files have 8.3, sometimes not, depending on
>> the name of the files which is different. some use x_yy, some
>> xy instead of x.yy. this is still confusing.
>
> Yes, developers used their own filename conventions. In the earlier
> days, we tried to use 8.3 naming standards. But not everyone - some
> used long filenames, assuming that people will probably download these
> files onto a computer like Windows, Mac or Linux .. which all support
> long filenames. Over time, more people used the longer filenames.
I run into this on my own from time to time. I already used semantic
versioning, YYYY-mm-dd, dd-mmm-YYYY, ...
Now I simply use release numbers for my own software, i.e., I just
increment a single number by 1 before the release.
> All of that makes cleanup really hard. There's not "one perfect
> solution" for this.
I guess, you knew this before. ;-)
Therefore you avoided to start the task at all until now.
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
