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
[–] [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
    •