D.eSystem 6.1.5 can show the directory in the new explorer which is curently in development. The new explorer got 2 startmodes,the normal mode and the debug mode which keeps the test_read tests from older D.eSystem versions. (D.eSystem is runing on real hardware on the thumbnail)
Find D.eSystem 6.1.5 here: https://github.com/D-electronics-scratch/all_D.eSystem_versions/releases/tag/v.6.1.5
Honestly, something feels really hokey with that repo. The release 6.1.5 release (the only release) was made 30 minutes ago, but the latest commit in the repo is from July 16. In fact, there are only 9 commits in the whole repo and they were all made on July 9th and July 16. All the tags were made on one of those two dates as well. Plus, all the tags from v.6.0.9 through v.6.1.5 (8 tags total) point to the exact same commit. Can you explain what on earth is up with all this? Is the release built from the same code as the v.6.1.5 tag points to, or is the commit built from a different, (unpublished?) version of the D.eSystem source code? Are you the sole developer of D.eSystem?
And I guess while I’m asking questions, were LLMs used in the development of D.eSystem?
The repo structure is still in progress. I originally uploaded the full source as release packages instead of pushing incremental commits, which is why the tags currently point to the same snapshot. Im reorganizing the repository so each version will have its own commit history and proper tagging.
The 6.1.5 release is built from the same code as the tag (nothing unpublished.)
And yes, Im the sole developer. I only use AI for explanations or debugging, not for generating code.
Im cleaning up the repo structure soon.
No, it very certainly is not (unless all versions since v.6.0.9 have all been built from the same codebase, which can’t be squared with your occasional posts boasting new functionality with each new version). All tags from v.6.0.9 onward point to the same commit: 6e5a84d.
I’m uncertain whether the released .iso files all are built from exactly the same code as is in the corresponding source release .zip file on the releases page. (And I don’t think I’d take you at your word if you said they were given how hokey this repo is.) But the tags on that repo at least are 100% pure fiction at best.
The tags from v6.0.9 to v6.1.5 currently all point to the same commit because I didnt push the actual development history to GitHub yet.
I was developing locally and only uploaded the source snapshots as release archives, which makes the tags look incorrect or “fictional”.
The ISOs are built from newer code, but that code hasn’t been pushed to the repo yet — that’s why the tags don’t match the releases. And the newer code is based off the older code.
I mean, that doesn’t make the tags look fictional. It makes them fictional. Full stop. You’ve got tags in the repo pointing to code that isn’t the code used to build the corresponding .isos.
I think if you’re not to the point where you’re willing to make the repo accurately reflect what’s in the releases, then you’ve published too early.
I say this speaking as someone who is working on a fairly long-term-ish project that I haven’t published at all. Source code or compiled form. I also haven’t started a local Git repo for it. The most I’ve done is talk about the unpublished project with screenshots of its output and some totally unscientific benchmarks. It is my aim to get it to the point where I feel like I can publish it soon, but when I do, it’s my intention to make sure it’s run as a repo and not just as free hosting for release .zips and .isos .
What should I do in your opinion with the repo?
My recommendation:
Every-D.eSystem-versionrepo that you already have for historical releases.all_D.eSystem_versionsrepo.D.eSystem.Every-D.eSystem-versionto indicate it won’t house any version greater than 6.1.5 and link to theD.eSystemrepo for newer versions.D.eSystemrepo as the initial commit.D.eSystemrepo 6.1.6.D.eSystemrepo referencing the 6.1.6 tag.D.eSystemrepo and tagging the exact commit you build the release off of.There are all kinds of more advanced topics in the field of release management like https://en.wikipedia.org/wiki/Reproducible_builds and nightly builds and automated test suite running and such. But the above will solve the immediate problems.
And I use AI just for learning,explanation and debuging
Yes,its build on the same source code like D.eSystem. I am the real developer,but I am still organizing this repo,I had planded to pack every source code on the main page but I packed it in the releases,I was already thinking about removing these commits.
Ok, so you are saying that the source code for D.eSystem isn’t in the repo (even if it is (maybe?) available on the “release” page as a .zip archive).
Methinks you need to spend some time figuring out how to use Git like a normal person.
You are right, the repo structure isnt in its final form yet. I originally uploaded the full source code as release archives instead of pushing each version as proper commits, which is why the tags currently point to the same snapshot.
I am reorganizing the repository so every version will have its own commit history, proper tags, and the full source directly in the repo instead of only in releases.
Im fixing the Git workflow so it follows standard conventions. Thanks for your feedback:)