11
New update for my OS (D.eSystem 6.1.5) (lemmy.world)
submitted 1 month ago by to c/osdev@programming.dev
12 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 1 month ago* (10 children)

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?

  • permalink
  • fedilink
  • source
  • hideshow 10 child comments
    •
  • [–] [S] 2 points 1 month ago (6 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 3 points 1 month ago* (5 children)

    The 6.1.5 release is built from the same code as the tag

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] [S] 0 points 1 month ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 1 month ago (3 children)

    I was developing locally and only uploaded the source snapshots as release archives, which makes the tags look incorrect or “fictional”.

    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 .

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 1 month ago (2 children)

    What should I do in your opinion with the repo?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 1 month ago (1 child)

    My recommendation:

    • Stick the 6.1.5 iso and source zip file in the Every-D.eSystem-version repo that you already have for historical releases.
    • Delete the all_D.eSystem_versions repo.
    • When you're ready to make a 6.1.6 release, make a new repo named D.eSystem.
    • Update the readme in the Every-D.eSystem-version to indicate it won't house any version greater than 6.1.5 and link to the D.eSystem repo for newer versions.
    • Push the 6.1.6 version of your codebase to the D.eSystem repo as the initial commit.
    • Tag that initial commit in the D.eSystem repo 6.1.6.
    • Make a new release in the D.eSystem repo referencing the 6.1.6 tag.
    • Thereafter, follow atomic commit practices. But even if you don't follow atomic commit practices, don't make new releases without pushing the version of the code from which you built the release to your D.eSystem repo 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [+] [S] 1 point 1 month ago (2 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 1 month ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 1 month ago

    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:)

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (-1 replies)