@pacav69, I was just going by your statement that: since the date 15/09/2023 is not the same as 2013-09-13. I have not checked the files. I trust that you are on top of things.
Date and time , and version number is important, depends on the way you look at date , IE-> Jan-24-2023 or 9-9-2023 or 01-24-1982, 15-6-1990, yes it gets odd. I see it as Month/day/year -> 09-15-2023, Opinions on this will help.
I will ALWAYS use YYYY-MM-DD as it can have files from any time in the past and they will be in order, unlike all the other methods which are useless and confuse everybody.
Totally agree about YYYY-MM-DD being the only way to mark files. It's the only way to have easy, consistent, reliable, and correct sorting of those files. I understand that different countries have their own "standard" methods for writing dates, but I agree with @Glenn that YYYY-MM-DD is the only way that I will use. But @pacav69, my point with: is that "15" is not the same as "13". You had said that the newest files should have a date of September 15th, but the examples I pointed out all had a date of September 13th. That is what I was, and am, confused about. I'm assuming and trust that all the files are correct, I haven't checked, but I'm confused about your statement that the files should have the date of the 15th, when the ones I found have the date of the 13th.
That is strange because I edited the code on the 14th and he compiled it on the 15th, so very strange
gentleman please let me settle this date issue. The files are dated as in the date of compilation and uploaded with that date. As i'm in Australia and we date things as DD/MM/YY or sometimes DD/MMM/YYY where MMM is a three letter month so 15th of september 2023 becomes 15Sep2023 or 15/09/2023 AEST. If i view the date in the ftp app it is what my system date is currently set to, which is AEST which stands for Australian Eastern Srandard Time. If you are in a different time zone i applogise for the confusion. If you read my changelog file on github you will see that i use the date format of DD/MMM/YYY to avoid confusion.
in the file '!!Make.SetupS-Project.cmd' located on github and as part of the devlopment package i created these remarks to ensure that future developers follow the same pattern. :Set parameters @REM change the ProjectVersion @REM so that it reads ProjectVersion= YY.MM.DD.0 use ONLY numbers @REM seperated with periods in the form YY.MM.DD.0 @REM use the date of compilatation YY.MM.DD.Incremental number usually 0 @REM where YY is the two digit year, MM the digit month, DD two digit day @REM eg set ProjectVersion=23.07.23.0 set ProjectVersion=23.09.13.0
True, that's how Freezer and I always had it since at least 2014, it just makes sense to drop the first 2 digits of the year as very few of us will be around for the next time either of them change
the reason is that the htm file was altered and i recompiled it on the 15th making sure that developers who use the dev package had the updated htm file and the latest code,
yes but i was uncertain at the time and there was no document stating the file version thats when i added the comments in the file so it was clearer
@pacav69 and @Glenn: @pacav69, I appreciate you trying to settle the date issue, but let me try. There are two different dates involved here. 1) There is the date that is in the file title, which in this case, for SetupS related files, is the ProjectVersion date of 23.09.13 as you indicated here, which is the date that I thought you were talking about, since that is the date that everyone sees when they look here. But when you said: that is NOT the date you were talking about. You were talking about the... 2) file timestamp, admittedly usually referred to as the date of the file. But you have to be careful when referring to that date since we are a group literally scattered around the world. When I, located in the US, look at the SetupS files here "directly" through FileZilla, and I assume that the same is true for WinSCP, I see that all of the SetupS related files have a Last modified timestamp of "9/14/2023 7:11:xx PM" where the xx varies as to when that file got uploaded. I don't see any files dated 9/15. When I download those files using FileZilla with the option to "Preserve timestamps of transferred files" the timestamp is indeed preserved and that becomes the timestamp of my local copy of those files, no matter when those files are actually downloaded to my computer. Since you and Glenn are halfway around the world, I assume that is the reason that those files have a timestamp of "15/09/2023" for the two of you as shown in your pic of the ftp view of the SetupS suite files in files directory. Bottom line, we have all always been talking about the same correct files this entire time, but have either been referring to the two different dates or to the date as we see it in our local time zone. In the future, to avoid this confusion, we should probably refer to the exact file title, since that will be the same for all of us and will not change no matter where we are. Whoever uploads the file always has the power to name that file in such a way to uniquely identify it. Another option would be to either always include the time zone when referring to the timestamp of the file or use GMT, but I would find it annoying to always have to do the time zone conversion. I'm sure to mess it up. It just seems less confusing to use the file name. Just for reference, it seems you two (?) are probably in the same time zone, Freezer and I are both in US Eastern, and Ghost and Trouba are both in US Central.
Yep, the version number will always go up, so it will never matter what the date says as we include a md5 that makes it irrelevant
@bphlpt yes it was my mistake and i take full responsibility for not changing to the correct format next time i think i will use Zulu time just to make sure i'm talking about date/time. If you want the latest and greatest check the github files as sometimes i make minor changes that don't effect the functionality of the apps and any changes are recorded in the changelog file. I don't want to update to the other sites every time i make a minor change as it is time consuming and i'm trying to automate the process so that a developer can use a cmd file to update the other sites without the tedious task of click here login there workflow. In the future i will not announce any updates it will be upto the individuals to check themselves. If you have ANY issues, raise them on github as i created documents to give users instructions on what to do. Glenn and I have been using github as a method of colloboration and seems to work well, after some time someone will have to manage the files.
in retrospect perhaps i should have incremented the number at the end but it was so minor i thought it not necessary
Nah pacav you don't have to do extra work, Git will auto fetch your changes for me and hopefully you'll inspect and commit to main my changes as I update files too -EDIT- As someone who has barely used git in my life, I picked up how it works pretty easily, and the fact you can easily revert, collaborate etc. makes it the best way to work on any project.
Not at all, @pacav69. As far as updating the files, you did absolutely everything correctly, as thoroughly as anyone could have. We all very much appreciate all you have done lately both updating and documenting what you have done, an aspect of file maintenance that the rest of us, including myself, are sometimes pretty lax at. If you had said: "The latest version is 23.09.13.0" I wouldn't have thought another thing about it, I wouldn't have said a word, and this latest page or more worth of comments would never have occurred. I misinterpreted what you meant, and I caused all of the commotion. I hope we can always maintain synchronicity between LastOS, Virgitec, and github, eliminating another possible source of confusion. I'm sure that we can automate some kind of method to make this as easy as possible. I am glad that you and Glenn have come up with a way to collaborate well together. I'm sure it helps keep both of you motivated.
